Ask HN: Best Linux sandbox? | Hacker News Reader

Ask HN: Best Linux sandbox?

83 pointsInsideTheBox44 comments

After the recent Firefox incident I realized how I lied to myself by believing that I'm secure just by using Linux.

My setup is Ubuntu 14.04 LTS (job requirement) with XFCE. So here's my question:

What is the best Linux sandbox available right now?

Even better if it's something simple to use and battle tested. Main things I would like to sandbox is Firefox, Thunderbird, Wine, Torrent stuff and maybe Chrome (is it necessary? my chrome://sandbox shows YES to everything except "SUID Sandbox")

View on HN

Fedora and Red Hat (+ the Red Hat clones like CentOS) have a "sandbox" command which uses SELinux to sandbox applications or entire X sessions and the applications inside them. For more info see [1] [2]. I've used it for a long time and it works well enough. It's not available in Ubuntu, though.

In Ubuntu the closest thing to it, I think, is AppArmor, but I've never tried it myself. Or you could run a virtual machine with Fedora and use SELinux there.

[1] http://danwalsh.livejournal.com/31146.html

[2] http://www.bress.net/blog/archives/195-Firefox-in-a-sandbox-...

Qubes? https://www.qubes-os.org/

Important reading for everybody:

http://theinvisiblethings.blogspot.com/2011/04/linux-securit...

There is apparmor(used by Snappy) that already allows you to lock down an process. In Ubuntu wiki they mention that there is some sort of Firefox profile, no idea if it is any use for daily driver though :)

AppArmor is great for incrementally sandboxing parts of your environment. I'm pretty sure the ubuntu repos contain a set of profiles for common applications like Firefox which you can choose to enable. It's very easy to write your own profiles too. Just save it into /etc/apparmor.d/ (I always make the name of my own custom profiles start with "local." so I don't mix them up with the repo-provided ones) and then run "sudo aa-complain FILENAME" to put the profile in non-enforcing complain mode. Watch syslog for a bit to make sure your profile isn't too restrictive, and then once you're sure the profile is good, switch it to enforce mode with aa-enforce. "sudo apparmor_status" tells you the current modes of all profiles.

Here's an apparmor profile I made to lock down the Skype linux client: https://gist.github.com/AgentME/5640268 . It works as a whitelist listing out exactly what Skype can access. I've got another profile for Steam (and all games that Steam starts up) which just blacklists a few directories (and lets me know if Steam or any games ever tries to access those).

Amazing, if even Skype works I'm sure anything else does. Testing it right now.

Are you / is AppArmor using a separate X11 instance for these? As otherwise, forget about it, I wrote about it here:

https://news.ycombinator.com/item?id=8652228

Ugh, that's a good point. I don't think AppArmor does any restrictions on X11 use. (I think it supports some fine-tuned controls on dbus usage though, so the idea isn't completely out of scope.) I guess it's better to think of AppArmor like a tripwire than a full sandbox if you open up an app to X11.

Yes, if the tripwire raises an alarm instead of triggering a bomb. A bomb would stop the attacker by killing/injuring him, which is not the case here (he can just come back with X11 exploitation code).

Maybe you can use docker instead?

http://fabiorehm.com/blog/2014/09/11/running-gui-apps-with-d...

https://blog.jessfraz.com/post/docker-containers-on-the-desk...

I was told docker runs things as root and is not secure, just convenient.

There's no reason a Docker container has to run as root. The daemon does, but that's another issue.

If you are connecting to X, it doesn't matter. You can attack all other X11 clients by design. This is why GNOME is pushing so heavily on xdg-app (for the sandbox) and the wayland-enabled GNOME shell (so apps can't snoop on each other).

Wayland doesn't have the Xinput disaster.

Subuser uses XPRA, so it shouldn't suffer from this problem: http://subuser.org/news/0.3.html#the-xpra-x11-bridge

There's actually a project called Subuser https://github.com/subuser-security/subuser which uses Docker to secure desktop applications.

Thanks for sharing, this looks interesting.

X11 forwarding doesn't cause any problems? I imagine I would easily be running 6 sandboxed apps at the same time.

From what I heard you can escape docker anyway so I would need something like SubUser (suggested by amouat)

Docker is just a container and not a sandbox. There are no controls in the kernel to prevent something from leaving the container unless you enable restrictions outside of docker such as SELinux. There is a lot of development around SELinux+Docker right now.

Haven't tried mbox yet but Firejail is pretty straight forward to sandbox locally installed apps. You can roll your own namespaced sandbox with unshare but Firejail does that cleanly, adds seccomp support, and is easy to use.

Docker, LXC, Nspawn and other container oriented managers are more focused on running chroots in namespaces so you would need to install the app in the container. In a way a container, especially an unprivileged one is perhaps a bit 'cleaner' as the app is installed in its own chrooted OS and not on the host.

The only thing is running GUI apps in containers is involved in terms of configuration, so Firejail wins for simplicity. Firejail also supports chroots so you can run proper containers with it.

We have a writeup on running accelerated GUI apps in containers here - https://www.flockport.com/run-gui-apps-in-lxc-containers/

does firejail protect your filesystem from the application? can the recent firefox exploit steal your ssh keys if firefox was run under firejail?

https://l3net.wordpress.com/2014/09/19/firejail-a-security-s... https://l3net.wordpress.com/2015/02/19/firejail-a-security-s...

By default, firejail seems to allow read access to my entire home directory. I believe you have to use the --private flag for it protect you from the recent firefox exploit. And if you want persistence, you can use the --private=directory flag.

You are distributing an outdated chromium with your demo app - this demonstrates quite clearly the problems with this approach: how to update software?

To clarify, this is a preview GUI container, more to show users how to run GUI apps in containers than a Chromium container. You are right hough, We ideally need to keep it updated but it can also be updated directly by users inside the container.

firejail and mbox (not to be confused with the mail storage format) are two good tools for GNU/Linux that employ namespaces and seccomp-bpf from a sandbox-oriented perspective.

Both have been discussed on hn:

Mbox: https://news.ycombinator.com/item?id=7214419

Firejail: https://news.ycombinator.com/item?id=8187534

What's the recent Firefox incident?

Nevermind: https://news.ycombinator.com/item?id=10021376

Perhaps https://blog.mozilla.org/security/2015/08/06/firefox-exploit...

You should try using nsjail, which makes using namespaces and seccomp-bpf easy. It's very simple, it's made to wrap existing programs with a single command line invocation. Done and done.

https://github.com/google/nsjail

How about a virtual machine? E.g. kvm, virtualbox, or similar?

I run my development stack on a few VMs and honestly even with Vagrant or others solutions the overhead/resource usage is noticeable and it doesn't feel that nice. It's fine for dev stuff though.

I imagine you're suggesting something like X over SSH, right? Do you use something similar on a daily basis? I would probably commit sudoku if I had to use the entire VM (not headless).

It's the X11 protocol which is the problem. Doing a desktop app in a VM without using something like VNC (ssh -X) doesn't really help.

Even VNC clients sharing clipboard content with the host system poses an attack vector, for example.

seems like the amount of malware able to escape through an up-to-date firefox, running with ublock/umatrix, running in an up-to-date linux distribution, running inside an up-to-date virtualbox should be very, very small: in the end of course nothing is fully secure, but IMHO unless somebody has to fear state-level actors firefox + ublock/umatrix + virtualbox is more than good enough

Of course this does not mean doing all of the browsing within the same vm, multiple vms for different things (banking, development, internet radio with flash, ...) after all RAM at least on the desktop is still fairly cheaply available, and on laptops one can still run a few browsing vms in 16gb if the need arises.

I compartmentalize stuff in VirtualBox VMs. I never share clipboard, and only install guest additions when I want a large display or shared folder. There is substantial disk space and RAM overhead, but both are inexpensive. And CPU overhead is small.

I wish we could turn this into a poll somehow so that we could get community-consensus on which sandbox option is the "most" secure from all the options provided.

I do have to agree with OP on the statement:

>> After the recent Firefox incident I realized how I lied to myself by believing that I'm secure just by using Linux.

Linux was promoted (partly) on the premise that is was more "secure" than Win, due to being open source. All the attacks since 2011/2012 (at such a large scale) seem to indicate that it isn't as secure as we think.

That's not my point. I don't feel safe at all when I have to use Windows. What I mean is that Linux alone isn't enough even for simple internet browsing, we need to be extremely paranoid and use all the tools available. Adopting that whole "web security stack" (noscript, ublock, no plugins, etc) is a important step but also gives you a sense of false security.

Uhm... why not plain old SELINUX?

Plain SELinux would not have prevented this as Firefox would run in your users context (unconfined_t), The alternative is, the sandbox command: https://danwalsh.livejournal.com/28545.html

SELinux can certainly work, even without using the great sandbox command. Your SELinux profile only grants Firefox read access to your files because you might want to use it to upload some of them; revoke that permission and leave it only the ability to read your browser profile and the problem is solved. Of course, the exploit would still expose things in your browser profile (bookmarks, history, saved passwords).

The sandbox command mitigates that by showing the browser an empty home directory, so that each time you launch it it will create a new profile with no such data in it. Note that a long-running sandboxed Firefox could still have a decent amount of history to expose. Best to start a new one for each site you visit, if you can stomach it.

Security always involves tradeoffs.

Define sandbox. I'd give firejail a try.

Something that "emulates" all the necessary parts for an application to work or that works without giving access to the entire machine, or more permissions than it needs.

Also if they gained full control of that environment they could destroy everything without affecting my entire/real system.

Are you using firejail?

Also, should I just wait for Snappy packages?

Docker is build on lxc. I found lxc more easy to use than docker There is flocker an app engine for lxc Also lxd the next generation hypervisor for lxc id very promising

Reply on news.ycombinator.com