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.
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.
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.
No, the GPL isn't magic.
Fun fact, both of these drivers are pretty much copy-pasted from Linux with little changes -- thanks to LinuxKPI, a layer that reimplements some Linux kernel interfaces on top of FreeBSD's.
So, it's doable. There was also a project a long time ago that combined virtualization with Windows to use its drivers. Stuff like that seems best solution for now where we can incrementally build native drivers over time. At least until cross-platform synthesis is built and takes off. ;)
There's a reason there's so little non-oss software support for Linux.
Barely runs on x86, and some very specific armv8 SoCs.
From the wikipedia capabilities article:
>Capabilities as discussed in this article should not be confused with POSIX 1e/2c "Capabilities".
Also refer to the Genode Foundations book, chapter 3.1.
User namespaces slowly but surely help retrofit the "principle of least privilege" to GNU/Linux, and that is good.
Linux sandboxing improvements in Firefox 57 (morbo.org)
276 points, 6 months ago, 103 comments
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...
I used that one to route all of my GMail stuff over my server. This is done transparently to Thunderbird, by launching it in its own network namespace. That way, I don't get these annoying "Someone has your password" messages when travelling.
I should generalize my stuff and push it to Github...
$ firejail --appimage Firefox-*.AppImage
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  leaves a bad feeling.
Though there's nsjail if you want something better written/cleaner.
Sadly this thread never gained traction, but I'd love to read more discussion about this: https://news.ycombinator.com/item?id=13838596
(Link for convenience for others)
Is it worse than running Firefox without firejail?
If yes, I don't know. Maybe a 'strong' apparmor/selinux policy might capture some exploits, firejail tries to mitigate?
Other yes, clearly: A Firefox exploit would usually not result in root access (unless it's combined with other Linux exploits) - in the case of firejail, it would have resulted in a root exploit.
I'm not saying: Don't use firejail at any cost. But I'm trying to say that you shouldn't have a false confidence in your security, just because you are using firejail and this because their current practices doesn't seem ideal for a security product. At the moment firejail advocates sound like that firejail is 'a proper security solution for Linux desktop', but given the circumstances, it's not.
might be worth checking out tor-browser-(bundle?) apparmor profile/s
I suppose one should use https://www.qubes-os.org/.
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.
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.
FileReader was a big step forward that took forever to arrive. Where's FileWriter?
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.
The important question is whether the APIs that CAP_SYS_ADMIN and other capabiloities grants you access to are potential security issues in an user namespace.
Dropping things like CAP_NET_ADMIN in a namespace is useful, because helps reduce the attack surface further.
So I would like to see a detailed analysis what doors CAP_SYS_ADMIN really opens. But I am very skeptical that this the right thing to do.
I wonder why they need CAP_SYS_ADMIN. I have used unprivilegded containers before. We needed to make some ugly compromises to have them do useful work, but CAP_SYS_ADMIN has never been required.
Would apparmor be a better solution?
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.