Hacker News Reader

Comment by wereHamster | Hacker News Reader

Run the browser in a container or in a sandboxed environment (kindof like chroot, but note that chroot itself should not be used for security purposes). There may be docker containers with just firefox, if not it's easy to create one. Or use vmware, though that is much more heavyweight than sandboxing or containers.

View on HN

Docker is not secure enough (it can help but it's not designed to be bulletproof). MAC (GRsecurity...) can be considered the "right" solution.

Or just give up and go QuubeOS ;)

Why, docker-initiated chroot would prevent FF from acessing any not-FF+libs files, including which this malware steals; on Qubes it would have access to everything user-readable in the AppVM, which may include some secrets as Qubes workflow involves user-supervised copying files across VMs.

Obviously docker, as opposed to Qubes, won't stop more complex malware that exploits the kernel.

From all I have heard, docker is not even secure enough to let user A do things in dockerthingyA and user B in dockerthingyB. From what I was told, user A could easily break out into dockerthingyB and maybe even the host. Are you sure it really is not possible short of exploiting the kernel (or docker I guess)?

I don't know the details, but this is rather due to fact how docker operates -- there is a daemon that runs with root privs (which are esential to create a container) controlled by a client with a protocol that has no concept of fine-graind access lists. Consequently, user A can do anything with user B's containers because docker doesn't even have such thing as container ownership. Also docker protocol involves something which is basically opening shell as root, thus users with docker access have also a passwordless sudo. All those choices are basically ok for docker because it is designed for single-user systems like developer laptops or application servers.

Currently, for multi-user systems the only safe option for containers is sadly virtualisation or emulation; nice implementation of rootless chroot is proot, http://proot.me/

Wouldn't selinux be enough? Browsers have no business touching files outside of ~/.mozilla or whatever.

I've run Firefox in a Red Hat/Fedora SELinux sandbox [1] [2] for the past 5 years or so. It is a little more tedious for things such as file uploads/downloads and cut-and-paste -- but worth it, IMHO.

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

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

Wouldn't this prevent you from opening local .html files?

How would you handle uploads or downloads then?

Explicitly configure appropriate permissions for ~/Download/Firefox?

I organise my files, I don't put everything into the same directory. I save them all over my file system. Same for uploads, I do not put them into one directory prior to uploading.

I think a better method is what Apple has done in OS X. When the app needs to read from or write to a user specified file, the app calls a specific API that presents a file picker dialog. The file picker dialog is running in a separate process from the sandboxed app, and the app will temporarily be granted permissions to access this particular chosen file through this API.

If you have a directory that you want to expose, you can set that up. It doesn't have to be just ~/Downloads/Firefox. If you want to expose something like ~/Documents but deny access to ~/Documents/Private you can do that. With a little effort, you can probably even configure a helper utility that toggles access on and off dynamically with a status charm in the notifications area.

That sounds incredibly cumbersome, akin to things like umatrix or noscript (which I use but 99% of users would never touch or be able to correctly control).

It's only as cumbersome as you choose to make it.

Docker would seem to me to be the wrong solution in this case.

Instead of

    $ firefox

you start

    $ docker run mozilla/firefox

and get instant process isolation and protection from these kinds of exploits.

Heck, mozilla could use the same underlying mechanisms internally (cgroups, namespaces) that docker already uses without introducing the dependency on docker (if that's whats bothering you). So while the implementation may not be ideal (installing docker is an overhead, I acknowledge that), what it does technology-wise is an improvement for security.

The new Firejail app [1] may be worth exploring as it is designed to run locally installed apps like browsers and games in sandboxes, as opposed to more chroot oriented container managers like LXC, Docker or Nspawn. They all use namespaces.

If you want to use a chroot oriented container manager its better to use an unprivileged container so you are not running as root. Currently only LXC has support for unprivileged containers. We have an experimental GUI app container with Chrome that can be used in unprivileged mode. [2]

You can even run your own sandbox with a simple command like this 'unshare -fp --mount-proc' That gives you a bash shell in its own pid space. You can expand this command further to use more namespaces like mount, net, user to get yourself a sandbox.

That is what apps like firejail and container managers are using, but its useful to know what's happening underneath. We are currently working on a guide on how to use unshare that may help. [3]

[1] https://l3net.wordpress.com/projects/firejail/

[2] https://www.flockport.com/apps/lxc-gui/

[3] https://www.flockport.com/how-linux-containers-work/

It appears that since we're discussing this on a page related to a firefox issue of exactly that nature that this approach is insufficient.

Actually, the nature of this vulnerability would prevent any attacks against docker

>> The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.

Moreover, since it seems you believe that javascript is a liability in this case (as much as I loathe the language: it's not!)

be aware that you still need to interpret javascript to read all of the pdfs you can find:

http://mariomalwareanalysis.blogspot.co.uk/2012/02/how-to-em...

(I also remembe reading something about opengl embedded in pdf, but I cannot find it anymore)

For windows there is a Sandboxie. http://www.sandboxie.com/

Sandboxie has gotten very good over the years. You can sandbox programs that even run with admin privileges.

edit: Don't think sandboxie can load drivers.

That's what I do. I wrote subuser.org and now I run everything in a subuser.

I created a docker container with firefox but everytime I launched it my network connection bliped. It wasn't a very good experience although we are talking about me using docker 1.3 when 1.7 is now out.

Reply on news.ycombinator.com