Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sandbox GnuPG, openssl and other external apps #2072

Open
BjarniRunar opened this Issue May 14, 2018 · 7 comments

Comments

Projects
None yet
4 participants
@BjarniRunar
Copy link
Member

BjarniRunar commented May 14, 2018

In light of today's PGP scare, it is probably worth exploring whether we can sandbox GnuPG, OpenSSL, and other external tools invoked by Mailpile. Most of the time, we do not want these tools making any network requests and preventing them from doing so would be good proactive security.

A very simplistic way to do this on Linux, would be to use LD_PRELOAD, and a library that causes network related requests to fail. Better would be kernel-supported containerization of some sort. Research would be needed to understand how/whether we can do this on other platforms.

Relates to #733.

@lanodan

This comment has been minimized.

Copy link

lanodan commented May 15, 2018

I think you can reuse Gentoo’s sandbox for that, it does filesystem and network sandboxing by using LD_PRELOAD.
Project Page: https://wiki.gentoo.org/wiki/Project:Sandbox

@vezult

This comment has been minimized.

Copy link
Contributor

vezult commented Sep 28, 2018

I'm not familiar with gentoo's sandbox, it doesn't seem like something that's going to be widely available. Firejail is probably something that would be more commonly included in Linux distributions. Using that, we could do: firejail –-net=none gpg ..., if we discover firejail is available on the local host.

python-seccomp: Not available in stable Debian or backports, if that matters (mailpile is available as a deb, right?)

It may be that we could write our own minimal sandbox using gaol from the servo project. It seems to indicate that it is cross-platform, to some degree. More research would be needed to determine if network access specifically is something that could be blocked on all target platforms.

More generally, we could build an apparmor profile for mailpile, or a firejail profile. That would be more comprehensive, but clearly not cross-platform.

@vezult

This comment has been minimized.

Copy link
Contributor

vezult commented Sep 28, 2018

OK, so gaol does not appear to have windows support yet. Anyway, if we have to provide our own sandboxing for some reason, that seems like it might be safer/better/more ergonomic option than writing something in C. That said, it seems like just targeting linux w/firejail may be the easiest thing at the moment.

@BjarniRunar

This comment has been minimized.

Copy link
Member Author

BjarniRunar commented Sep 28, 2018

Writing our own is a bigger task than we can handle; doing this sort of thing well requires low-level knowledge of OS specifics and we're spread pretty thin already.

I really like the idea of detecting and using firejail if it's available, and whatever is available and native on other platforms. I see firejail is available on my Ubuntu 18.04, so if it were a package dependency it'd just work! Putting the jail-specific-logic in mailpile.platforms would be appropriate (if it's small); that's where OS-specific stuff goes. Otherwise, mailpile.sandbox and mailpile.sandbox.firejail modules, if there is a large-ish amount of boilerplate.

The natural integration point would be mailpile.safe_popen, with sane (restrictive) defaults and new arguments to allow extra permissions (such as network access for Tor, or if/when we want GnuPG to contact key servers).

@vezult

This comment has been minimized.

Copy link
Contributor

vezult commented Oct 5, 2018

I'm working on this, FWIW

@vezult

This comment has been minimized.

Copy link
Contributor

vezult commented Oct 9, 2018

While I'm currently focusing on Firejail, the bubblewrap project provides a comparison of several sandbox projects and the tradeoffs involved in each.

@norpol

This comment has been minimized.

Copy link

norpol commented Dec 6, 2018

@vezult Cool! I guess right now it's only firejail, but it's nice you're writing it in a way that it can support other sandboxing tools as well.

I'm sorry for adding "yet another sandboxing solution" to the discussion, but considering that a firejail exploit can possible lead to direct root access on a system...
It's probably worth to suggest an alternative such as gvisor. Especially because it's a user-space only tool (no root, no namespaces, no suid required), which also had vulnerabilities, but due it's nature no direct root exploitation is possible. Also there is nsjail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.