Linux sandboxing improvements in Firefox 60

[shakna]

> The most important change is that content processes — which render Web pages and execute JavaScript — are no longer allowed to directly connect to the Internet, or connect to most local services accessed with Unix-domain sockets (for example, PulseAudio).

Finally, some process isolation! That's something to celebrate!

Being able to wrap Firefox in an unprivileged chroot makes for a really nice addition to its security.

[xnyanta]

That's pretty nice to see.

If I am not mistaken, Tor Browser has already been using this technique for some time to thwart malicious connections from leaving the browser. All traffic is communicated to the tor client via a unix socket.

[snvzz]

>Unprivileged user namespaces had some security bugs in their initial Linux implementation, and some Linux distribution maintainers are still wary of keeping them enabled.

Unsurprising. These are all a pile of hacks to try and fail at making up for the fact Linux doesn't support capabilities (not to be confused with POSIX Capabilities).

Fortunately, projects such as seL4 and Genode do exist, so it might be possible to, at some point, run a browser on an actually sane environment.

[AnIdiotOnTheNet]

I eagerly await the day some non-Linux kernel manages to achieve anywhere near the driver support Linux has.

[ajross]

You're going to need to be more specific. Linux does indeed have a feature called "capabilities", so it's not clear exactly which OS feature you are taking about.

[_0w8t]

With mount namespaces one can emulate capabilities usind bind-mounts and file descriptor passing, but this is indeed rather limited hack at best.

[civodul]

Nice to see this happen! In a similar vein, in Guix we've been discussing ways to run any installed program in its own namespaces, with only the appropriate resources mapped into them: https://lists.gnu.org/archive/html/help-guix/2018-01/msg0005... .

User namespaces slowly but surely help retrofit the "principle of least privilege" to GNU/Linux, and that is good.

[kalmar]

I'm curious why chroot is used instead of mount namespace and pivot_root(2). This would let them get away without CAP_SYS_CHROOT, while also providing stronger filesystem isolation.

[severine]

Previous discussion:

Linux sandboxing improvements in Firefox 57 (morbo.org)

276 points, 6 months ago, 103 comments

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

[zaphirplane]

I wounder what sandboxing improvement will be in 63 ;)

[esaym]

And if WebGl no longer works, try setting (in about:config)

  security.sandbox.content.read_path_whitelist

to

  /sys/class/drm/card0/device/config,/sys/class/drm/renderD128/device/config,/sys/class/drm/controlD64/device/config

[IronBacon]

>if the browser has been set up to use a proxy server, connecting directly to the internet is no longer possible.

I haven't followed the development, would this also prevent WebRTC IP address leakage?

Here IIRC I've simply disable it (media.peerconnection.enabled) and forgot about it...

[chupasaurus]

I'm running browser inside network namespace with VPN tun device, so the only address it could leak is a tunnel one.

[app4soft]

More sandboxing![0]

  $ firejail --appimage Firefox-*.AppImage

For details read Firejail's docs.[1, 2]

[0] https://twitter.com/app4soft/status/994938745072832512

[1] https://firejail.wordpress.com/documentation-2/appimage-supp...

[2] https://firejail.wordpress.com/documentation-2/firefox-guide...

[miduil]

Last year, afer a firejail local root exploit got released [0], I've completely quit following their project.

I don't want to discomfort the developers and I think it's stunning what they are creating...

But under the aspect that they are working on a security product, I'm concerned by their overall code quality and testing strategy.

They might want to consider taking a step back and reevaluating how they are going to direct their development in terms of secure (c-)coding practices.

*Disclaimer: Not a developer, just a sysadmin, but reviewing some of their code/profiles/CI-jobs in their git repo [1] leaves a bad feeling.

[0]: https://www.exploit-db.com/exploits/43359/ [1]: https://github.com/netblue30/firejail/tree/6830065197cc57489...

[muvek]

I was wondering if there are any benefits (security wise) in using snap firefox (snapcraft.io) instead of firejail. Can anyone comment on this?

[owaislone]

Nice. Waiting for them to publish 60 to the Snap store now.

[8bitsrule]

I don't know much about this topic, and appreciate sane levels of protection.

But when I use the menu in Snap Firefox (59) to open a file in another partition so I can read it ... and I can't do that because of 'permissions' ... I get irritated.

While I'm on this general topic ... I also don't like the fact that javascript won't let me write to a file. That would be VERY USEFUL.

In short, these long-term accumulation of these 'hardwired' restrictions is severely cramping my use of (and enjoyment of using) computers. If I want it, I have time to change a preference, but not to earn a PhD.

[tracker1]

Javascript can write to a file.. see jsshell, node and a number of other runtimes. However, you do not want browsers to have unfettered filesystem access. The language is perfectly able. You could possibly write an extension to do what you want.

[d33]

Interesting. Sandboxing in Chrome is something I turn off when I write my headless bots as it requires extra privileges. Would be nice to see a comparison between it and FF.

[jbroman]

If you're on Linux >= 3.10, I believe Chrome should use the namespaces sandbox rather than the (privileged) setuid sandbox.

https://chromium.googlesource.com/chromium/src/+/master/docs...

[staticassertion]

Can you elaborate?

[the8472]

> In this context, we'd like to remark that an application like Firefox only needs CAP_SYS_ADMIN, CAP_SYS_CHROOT, CAP_SET(UG)ID to achieve most effect

I hope they also drop those capabilities once they have achieved what they need. I also which other namespaces they use, the article only mentions user namespaces.

[tialaramex]

CAP_SYS_ADMIN is a catch-all where they dump all the things root has that didn't fall into another bucket. So if a program needs CAP_SYS_ADMIN then basically you haven't really got any meaningful sandboxing so far as I understand it.

[shmerl]

> Specifically, we use Linux namespaces and chroot.

Would apparmor be a better solution?

[sp332]

AppArmor isn't available on all distros - Fedora, for example. I think it's left up to the distro maintainer to set up AppArmor profiles.

[neolefty]

Are these improvements applicable to Android?

[rebelwebmaster]

Probably not since Firefox for Android doesn't support multiprocess.

[canuckistani]

No.

[devit]

> The one exception to the network policy, for now, is the X11 protocol which is used to display graphics and receive keyboard/mouse input

Well, this makes everything else moot, since you can just inject keystrokes and thus trivially take over the system... (in addition to probably many other vulnerabilities in the X11 server)

They should try to do a proper isolation job (meaning no I/O other than shared memory and pipes to another Firefox process), not this apparently useless effort.

[db48x]

If you have 10 problems to fix, the effort spent fixing the first 9 of them isn't "useless" as you say, just because you haven't fixed the 10th one yet. And they couldn't fix all of the issues by blindly proxying all IO through the main Firefox process, either, because that wouldn't fix the problem. It has to be able to _selectively_ proxy IO through the main process, and that takes time and effort to implement.

[upofadown]

>since you can just inject keystrokes and thus trivially take over the system...

From javascript in a browser? That would indeed be a serious issue. How would this work exactly?

[icebraining]

The keyword is "for now".

[ars]

You have a good point, but the way you are writing is unnecessarily aggressive. Emphasis on the unnecessary, it doesn't add anything so you should leave it out of your writing.

[jpetso]

Wayland to the rescue!