Firejail worsen security? #3046
Comments
|
First of all, it should be noted that the predominantly numerous security gaps, all of which were significantly discovered in the period 2016/2017 by an audit. At that time Firejail was still a brand new project, and anything but really mature. The initial flaws were addressed recently, and Firejail has since been hardened in many ways. There's even an AppArmor profile, which adds hardening to Firejail itself to effectively prevent potential problems. Furthermore, you should always take a close look at security holes, especially as some of the CVEs could only be exploited under local, rare, difficult, or completely absurd conditions. And from today's point of view, Firejail has undergone an enormous development, not least due to the great community behind it, and now has only rare or minor security holes. It's also not fair to compare Firejail with Flatpak or the underlying Bubblewrap which is used by Flatpak. Both pursue completely different goals. But if you strictly consider the question of security, then suid binaries like Firejail and Bubblewrap are basically problematic. Especially since the protection of suid binaries has always been difficult. The future Landlock LSM offers a much better foundation and would allow any process without root rights to lock itself in an effective sandbox. And this with an extremely minimal attack surface on the part of the Landlock LSM. |
That still does not get rid of the fact that firejail has large attack surface now. Just because vulnerabilities were fixed in the past, doesn't mean it's all fine now. Also the comments from the two experts linked above were not in 2016/2017.
And every firejail CVE was easily exploited. Please point out a single known firejail vulnerability that was only exploitable under "completely absurd conditions".
We are not comparing firejail with flatpak and bubblewrap is fair to compare to firejail.
Bubblewrap is much less problematic as it has minimal attack surface unlike firejail. Bubblewrap also doesn't need to be suid. It only needs to be suid when unprivileged user namespaces are disabled. |
In 2017 yes, but now not. And even if there might be more security holes found in Firejail, Bubblewrap isn't immune against new security holes too.
Why not take Firejail 0.9.60 and demonstrate a successful outbreak? If that's so easy, then this should be no problem. Example: CVE-2019-12499 To take advantage of this, Firejail must be run as root, which never happens in 99.99% of cases. This sandbox must be killed (e.g. SIGKILL) as root on the host to the right time, which also never just happens. These are conditions that are realistically never to be found, which makes this vulnerability little relevant. A sandbox that is started as root is basically insecure, and would also be a risk in the case of Bubblewrap.
Not really, especially since Bubblewrap is functionally very minimalistic and represents the opposite of Firejail. In principle Bubblewrap does not have the slightest claim to be something comparable to Firejail, and serves only as a minimal basis for other programs.
Less code does not mean that this code offers less attack surface than that of more extensive software. Even the supposedly smallest program can have extremely critical security gaps. It may be advantageous to reduce code if necessary, but this is not a guarantee for qualitative code. It is also not possible to make a well-founded statement about whether Firejail or Bubblewrap offers the larger attack surface, especially since it depends strongly on the conditions. Practically neither of them currently offers any program within the sandbox a real chance to extend privileges, and that's exactly what matters. And of course Bubblewrap requires suid rights, especially since user namespaces are quite questionable from a security point of view. The doubts about this have by no means been dispelled. In the worst case, you inevitably compromise yourself, which is why user namespaces are not always activated. |
|
There are two distinct scenarios:
Firejail significantly reduces attack surface for 1 (it may vary across different profiles) and increases attack surface for 2 (more or less). Everyone have to decide themselves what net attack surface impact is for them. Granting access to firejail for untrusted local unprivileged user may be not good idea (this is scenario for which most of past cve were applicable). The question is if today's desktop linux systems are multi-user focused (with some of them being untrusted). I heard many opinions from developers of projects like kernel or systemd stating that's not the case. Yes, bublewrap has less additional attack surface for scenario 2 but merely installing bubblewrap does nothing for scenario 1 unless someone write special wrapper for it with profiles for many specific apps. Something like that, let's call it Firewrap or Bubblejail would be interesting, perhaps more secure solution than firejail but for now it doesn't exist. |
No, it still has large attack surface.
I never said it was. It's just far less likely for it to have security holes due to its reduced attack surface.
Sure, that's like the only CVE with moderate complexity. Most other CVEs are very easy to exploit. Take CVE-2017-5207 for example in which a few commands was enough to get full root access #1023
Not as much as firejail. The only known sandbox escape in bubblewrap was CVE-2017-5226 in which an attacker could abuse the TIOCSTI ioctl which if anything, is the kernel's responsibility.
That's why it's so good.
I know. Bubblewrap's entire design is to have as little attack surface as possible. For example it doesn't even interface with raw syscalls for seccomp filters (you have to create your own seccomp filters with seccomp_export_bpf) and has really simplistic command line parsing containers/bubblewrap#317 (comment) Meanwhile firejail is constantly adding attack surface with pointless options like |
Sure, it can but firejail's large attack surface makes it far more easier to escape.
No, it's not just if it's a multi-user system. An attacker can compromise an unsandboxed program and then exploit vulnerabilities in firejail.
That's what I'm planning to do. |
Easier than for unsandboxed app? Obviously no. Was there a cve that worked inside sandbox?
Yes, however I consider scenario when malware author writes script that will compromise some app and then go for firejail as rather unlikely. 95+ systems won't have firejail installed. The situation would be different when they have unlimited time and tries like local users have. Also when someone gets arbitrary code execution then they already won even without root access. Most things that matter will be available freely inside home.
Great, please share your code. |
No, I meant easier than bubblewrap.
Yes.
Firejail is a setuid program with large attack surface. Many malware authors would go after it as it's such a vulnerable target. |
It depends on what bubblewrap sandbox would do. By default it does nothing but I agree that strong bubblewrap sandbox may be safer than firejail's one.
It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.
It works only when firejail is run as root, again it doesn't add additional attack surface on system.
Exploit need to be run outside sandbox
It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.
Exploit need to be run outside sandbox
This is sandbox escape but It doesn't add additional attack surface on system. Bubblewrap was also affected and fixed it couple of months after firejail did So to conclude above, none of those cve allowed to raise privileges when run inside sandbox in comparison to unsandboxed case. The point that attack surface is decreased in scenario 1 stands then. Obviously sandbox-escapes work inside sandbox but they don't increase attack surface on system.
Malware authors usually try to target as many users as possible (that's why they don't give a s*hit about linux in general 😄 ). It may be different if we're talking about high-value individuals but again, what they do after gain code exec is secondary issue. |
Vincent43
added
the
question_old
It doesn't. https://www.cvedetails.com/cve/CVE-2017-5940/ "which allows local users to conduct sandbox-escape attacks"
It doesn't. https://www.cvedetails.com/cve/CVE-2017-5180/ "which allows local users to conduct sandbox-escape attacks"
That's not what you asked. You asked for vulnerabilities that could be exploited from within the sandbox, not full priv esc from the sandbox. If you want full priv esc, then the attacker could have exploited one of the sandbox escape vulnerabilities I listed above and then exploited another priv esc vulnerability in firejail once they're outside the sandbox.
So they would want to target one of the most popular linux sandboxing programs, firejail. |
|
@madaidan The descriptions are misleading, unfortunately. You need to read the code and understand the vulnerabilities. There is no sandbox escape there (from the running sandbox), the primary problem is the privesc (edited).
There are already so many false claims in this thread that I don't know where even to start. |
|
Anyway, the thing is that there is little point to discuss Firejail version 0.9.38 or 0.9.44. Firejail changes very fast, and what will be upcoming 0.9.62 has not so much to do with the early versions that were hit by these vulnerabilities. It would be very cool if we could discuss the present and not the past. |
I am discussing the present and in the present, firejail still has far too large attack surface and is still recommended against by security experts. |
Well, my impression currently is a bit that some other security experts also just point to these mistakes of the past. They have been fixed! Also I don't buy into the argument that there are too many options. Many of Firejail's options don't do anything even remotely dangerous, and others are just interfaces provided for convenience, such as the cited |
Only a side note, the only difference between Firejail and Bubblewrap with regards to CVE-2019-12499 is that Firejail got a CVE assigned (it was requested by the project) and Bubblewrap did not get a CVE assigned... now, there are well founded reasons both to assign and to not assign a CVE in that particular case, but when comparing the projects, it would be fair to mention that the reasons not to assign a CVE apply to Firejail as well :) |
|
Once inside a sandbox - firejail, bubblewrap, or any other seccomp sandbox - you can not exploit any SUID executable present in the system. It has to do with the way seccomp is handled by the kernel. The attack surface of the program that configured seccomp becomes irrelevant. In other words, if you get control of a firefox running in a sandbox, the kernel wouldn't let you exploit the program that started the sandbox. CVEs: - most of them were reported by the people associated with the project. Most of the time we already had a new release out with the fix. We did get some CVEs from outside people, mostly SUSE guys. Also, they suggested the current user restriction we put on firejail executable (see man 5 firejail-users). So big thanks to all CVE authors.
Already explained above. We don't really care about the optics.
Yes, they do increase it. The attack surface visible to somebody outside the sandbox is large. Don't use this on enterprise servers, or any other multiuser system. Firejail was built for single-user desktops.
We don't seem to be very popular with bubblewrap people.
He doesn't seem too happy about flatpak/bubblewrap either. From the link:
You guys can use whatever you want, firejail or bubblewrap. In my opinion it is irrelevant. I would suggest what you are missing in whonix is some serious mandatory access control system (MAC). You already have some apparmor support, you need to beef it up and expand it to all applications you run, with strong profiles for all of them. By strong I mean 100 lines or longer each one of them. You can evaluate apparmor profiles by counting apparmor lines the same way you can evaluate attack surfaces by counting C code lines. Here in firejail we can get away with one single (small) apparmor profile shared by 100 applications because we target the home user market. In whonix you talk about political disidents, whistleblowers, repressive environment, reporting on organized crime... The security you intend to provide should be about 10x better than what we give to Linux home users with firejail. This means an absolutely crazy apparmor setup. Just my opinion... I don't know if it is going to help, but I wouldn't waste time debating firejail/bubblewrap. |
|
Quote @smitsohu #3046 (comment)
If the CVE descriptions are misleading, do you have security advisories, summaries or something? Or how do I learn more about these? |
|
Just to add, it is possible to configure Firejail in a way that the attack surface becomes smaller. As a rule of thumb, less attack surface means less powerful (which probably does not come as a surprise). One thing is the NO_NEW_PRIVS bit. Bubblewrap sets it unconditionally, and Firejail keeps a switch You can also take a look at other switches in /etc/firejail/firejail.config, for example the |
@adrelanos No. But the exploit was published, you can find it here |
|
Trying to wrap my head around this. First, terminology. First @madaidan was the first one to say
If my understanding is correct, @madaidan thinks running without firejail, the compromised application would have been "stuck" under the user account. (Ignoring other ways it might escalate from user to root or kernel for the sake of this discussion.) But since it was run under firejail, the attacker could have escalated to root or kernel privilege? In other words, was worse off than not using firejail? |
|
The argument that a setuid binary with a large attack surface is a potential threat seems fair to me. I'm wondering though, isn't this what LTS tries to address by stripping out some features? How much of a difference in code complexity does it make? Daniel Micay's work is on an OS that that desktop Linux could pretty much never compete with in terms of security to begin with. He seems to not like neither setuid nor unpriviliged namespaces, and has spoken out against Flatpak as well. I don't think Bubblewrap is going to be much better in his eyes, aside for its decreased attack surface (which is arguably important). Edit: |
|
Regarding BPF, Bubblewrap allows any random BPF code from user, which could be questionable. Firejail compiles BPF filters by itself (in a sandbox), so the contents are known. It would be easy to allow loading of user BPF filters. Bubblewrap does not allow application level IP firewalling. Then Firejail has higher level features like X11 sandboxing and it can also make throwaway copies of files to the sandbox. It's easy to compare SLOC counts, but then you should compare which part of that is running privileged and which is sandboxed. The major point with Firejail is that it is very easy to setup and has lots of profiles for common applications. This makes it very easy for non-expert desktop user to improve security. Otherwise, I think @Vincent43's theoretical Firewrap/Bubblejail could combine best of both programs. Getting to the same level of ease for end user as with Firejail would not be trivial and it would require changes to Bubblewrap too. One feature that MS Windows has that neither Firejail nor Bubblewrap have is full OS virtualization. Firejail could use KVM to make a small VM with tiny OS, which could then control the OS/application interface better than very limited BPF ever can. For example, this intermediate OS could force cache flushes for each system call entry and exit, to prevent Meltdown-like problems with speculative execution. Doing it always in host OS would hit the performance badly, so it is not done there, but for a single non-performance critical application it wouldn't matter. |
|
@adrelanos that ancient exploit, bug fixed years ago, depends on sandbox setup, and there is no immediate way to trigger a sandbox setup from inside a running sandbox. If you wanted to craft a successful attack from inside a sandbox like that, you would need to make additional assumptions, like reuse of the directory and evading detection. Admittedly, that CVE is a bit in a grey zone (which is why I updated my comment afterwards). |
|
After reading all the positions, it is noticeable that too much emphasis is placed on favorite software and false facts. I think we can say that both firejail and bubblewrap had shortcomings, as well as their individual strengths and weaknesses, and equally have potential for improvement. And given that we're all interested in creating more security, the focus should be on learning from each other to effectively advance linux security. It has been argued that firejail-LTS also exists. I'd also like to know how this differs from regular firejail, and if it wouldn't potentially make sense to make firejail-LTS the default. The question is to what extent the missing features would really be missing, or whether they were actually used. What do you think? Personally, I would have to admit that, despite extensive use, only a fraction of the functionality is really used. On the other hand, the reduction of functionality is not a basic solution for more security. What do you think about systemd to check all code of firejail and bubblewrap via fuzzit, coverty, oss-fuzz etc.? |
systemd? |
Nobody has said they weren't fixed. Firejail still has too large attack surface even though you fixed a few vulnerabilities in the past.
Do you have a source on bubblewrap also being vulnerable?
I know. I never said you could. I've only said an app inside firejail can get priv esc after breaking out and then exploiting a priv esc vulnerability in firejail since they now have access.
No, it's not just multi-user systems. An unsandboxed program can still exploit vulnerabilities in firejail even though it's a single-user system. I've already explained this.
Flatpak is not the same as bubblewrap. I've already said this. Micay does recommend bubblewrap. https://github.com/thestinger/playpen "use bubblewrap if you need more functionality " I've already said this too in the forum post linked above which nobody seems to have read.
We're already working on confining everything with apparmor using a full system policy https://github.com/Whonix/apparmor-profile-everything Bubblewrap is still important though as apparmor can't do namespaces or seccomp.
No, I mean from user to root.
No. Apps in firejail aren't anymore likely to gain root but apps outside of firejail (including sandbox escapes) can exploit vulnerabilities in firejail to gain root.
No, that's not true. If you try to use anything other than a valid seccomp filter, it will give an error:
That's a good thing. Unprivileged users should not have access to netfilter administration code. It exposes far too much attack surface and is one of the reasons unprivileged user namespaces are such a security risk.
It's easy to do that in bubblewrap and I've done it many times before.
Bubblewrap drops privileges properly.
Exactly. Firejail focuses too much on usability and making itself easy to use which increases attack surface substantially.
I've thought of making a wrapper for bubblewrap that makes it easier to use for a while now. |
So you can have bad people compromising regular programs, and bad people compromising sandboxed programs. Hopefully we can take care of the ones attacking the sandboxed app.
The idea would be to sandbox as many apps as possible. At least the network-facing programs, and software not included in your package manager you install manually - like obscure pip packages. The sandbox defends only against external threats, and is useless for the ones that are already inside your system. |
We tried to remove rarely used features, debug tools and so on. It was about 40% of the code.
I agree with that. The attack surface is still large. I estimate about 10% of the users are going for LTS. I'm not sure what they go for, the reduced attack surface or the stability. My guess would be the stability. Some people people say the version in Debian stable could be considered an ESR version. |
|
@madaidan The BPF program could be evil while not being invalid. I don't see how firewalling could increase attack surface (on the contrary), what do you mean? |
|
I think we gave you all the information you requested., just read our responses again. I'm closing the discussion for now. |
|
Thank you guys for all the comments been put here, i really appreciated. Wish for you all the best and success and thank you for making the (technological) world better 💟 |
|
Interesting thread. So many differing opinions and argumentation in the security community - especially when it comes to Linux (because there are so many options: apparmor, SELinux, lxc, docker, firejail, etc). Hoping to find a source that consolidates all of this better soon. |
|
Sorry for chiming in late. @madaidan What sandbox alternatives do you recommend if I was a political dissident in a tyrannical environment? |
|
I don't think any simple sandbox solution is enough for extreme scenarios. I would advice to look at holistic security solutions like QubesOS however this would need to reinvent the way you use the system. |
I'd generally recommend AppArmor or, preferably SELinux, along with bubblewrap. AppArmor doesn't make other sandboxing solutions redundant as it still can't utilize seccomp or namespaces. Applications confined under a strict AppArmor policy are still exposed to a considerable amount of kernel attack surface unless paired with a decent seccomp filter. We're working on sandbox-app-launcher for use in Whonix: https://github.com/Whonix/sandbox-app-launcher
Security within the VMs is still important when using QubesOS. You should use a strict sandbox inside a VM for defense in depth. |
|
@madaidan I looked into AppArmor and SELinux. It's cumbersome to configure SELinux because its configuration is spread across multiple places. I prefer AppArmor's simpler configuration model. How are you going to filter dbus? bubblewrap doesn't do dbus filtering. Where do I find you for discussing sandbox security? |
AppArmor supports fine-grained D-Bus restrictions, or you can use separate users like sandbox-app-launcher does.
https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008/ |
Currently, I create my own sandboxing mechanisms using bubblewrap, seccomp-bpf and AppArmor. Also, Firejail is supposed to be somewhat insecure: netblue30/firejail#3046
Currently, I create my own sandboxing mechanisms using bubblewrap, seccomp-bpf and AppArmor. Also, Firejail is supposed to be somewhat insecure: netblue30/firejail#3046
Currently, I create my own sandboxing mechanisms using bubblewrap, seccomp-bpf and AppArmor. Also, Firejail is supposed to be somewhat insecure: netblue30/firejail#3046
Currently, I create my own sandboxing mechanisms using bubblewrap, seccomp-bpf and AppArmor. Also, Firejail is supposed to be somewhat insecure: netblue30/firejail#3046
Currently, I create my own sandboxing mechanisms using bubblewrap, seccomp-bpf and AppArmor. Also, Firejail is supposed to be somewhat insecure: netblue30/firejail#3046
|
Here's another perspective on security and privacy. Firejail has its flaws, but it is the only thing that does what I want. I decided to use firejail after agonizing over the choice between firejail and bubblewrap. bubblewrap doesn't execute programs in an existing network namespace. firejail does. I really want to execute programs in tor network namespace which forces applications to connect to the internet over tor. I could even create VPN network namespaces. The privacy benefits are immediately tangible, and if I sandbox all potentially compromising programs that I run with firejail, net attack surface of my system may get reduced. Often, security and privacy don't mix well together. Google's chrome browser is intent on infringing user privacy, but it is the securest browser. I don't want to voluntarily offer my information to big tech companies like google and microsoft. For big tech companies, safety and security are code words for control. I mean when big tech companies talk about security, they actually mean control. Control of user data is one form of control. They(windows, MacOS, and google chrome) may be better for security, but the additional security they provide is just another way to make sure that they are the only ones that collect user data and that a user's system is locked down so that they don't have any freedom with their operating systems. Secure boot is one example. It may help a user prevent hackers from modifying boot process, but microsoft has tried and failed for many years to prevent windows computers from installing linux through secure boot. Privacy is the reason that I keep my smart phone off unless I absolutely need it for SMS verification or other things. Smart phones may be locked down tightly, but they will leak your location to big tech companies like apple and google. Big tech companies have been known to give their users' location data to government agencies. Even if you turn off location tracking, location tracking stays alive in the background until you turn off your phone. Without freedom and privacy, security doesn't mean much. Let's hope that landlock LSM gives birth to a better sandbox platform in the future.
|
I have good news for you :) https://github.com/Eloston/ungoogled-chromium
And more good news: https://grapheneos.org/ |
|
I think qutebrowser and librewolf are better in terms of privacy than ungoogled-chromium. Librewolf specifically focuses on eliminating telemetry.
I don't know whether grapheneos prevents location tracking. Cell towers, GPS, WiFi, and bluetooth constantly track smartphone location. But, grapheneos seems better for privacy than android. |
Yes, but to have great privacy you need better security than a Firefox fork, right? But I suppose you've mitigated that using firejail. Back when I compared all of them, ungoogled-chromium had the lowest amount of telemetry - but would like to hear what ungoogled-chromium has that qutebrowser and librewolf don't - if you know...
It is hard to find good references on such things. GOS doesn't have any tracking in the OS, but it is hard to know what cell towers can accomplish with the closed source radio firmware. The GOS developer is very open for discussion (in the chat rooms) if you can determine anything that they've missed: https://grapheneos.org/contact |
I'm going to be honest. I assumed that qutebrowser and librewolf would offer better privacy than ungoogled-chromium because
Location data are still accessible from government and big tech companies even if apps don't have access to location. Smartphone location data are used for contact tracing which is just a cover for taking away freedom of movement and freedom of assembly. As I wrote, for big tech companies, security is just another way to lock down options and control users. They have better security because they want more control. Security that leads to more oppressive control is not a good form of security. |
|
ungoogled-chromium has removed all telemetry, it does not do any network connections without user interaction. Be aware that some source to get ungoogled-chromium update very later/irregular => worst security (unpatched public vulnerabilities). |
|
Since the topic is derailed:
Firefox + arkenfox.js + uBlock Origin is great. My brace provides that out of the box. Brace also provides a enterprise policy override to harden Chromium. I also provide Mull for that same configuration on Android.
For devices not supported by GrapheneOS, I offer DivestOS.
You might also want to see this and this and also this and this. |
|
Anyway, the point is
|
|
Anyone have a security comparison for running browsers in flatpak vs firejail vs podman vs docker (non-root)? |
|
flatpak isn't just a sandbox. It is also a packaging standard. If you don't agree with flatpak as a packaging standard, you don't want to use it. You may not like the way specific flatpak packages are packaged. Docker is a reproducible application container. Each application container comes with its own configurations. If you want to meddle with container's built-in configurations, you better create a new container. Creating a new container is cumbersome. Podman is a drop-in replacement for docker. Flatpak, docker, and podman don't have as much flexibility as firejail. Firejail lets you configure your applications as you like. You use flatpak, docker, and podman when you want to just accept pre-built application configurations. They are good for sharing pre-configured applications in corporations, but they are cumbersome for individuals. If you want something comparable to firejail, you better create an application sandbox on top of bubblewrap. |
Hi,
Firejail/firetools included by default in Whonix Anonymous OS distro for the security benefits of sandboxing, but recently discussion appeared that Firejail is worsening the security of the OS and i will copy (with rearranging) the arguments here:
High rate or hole of privilege escalations: references CVEs and Seclist discussion.
Firejail bulky code and complexity increases security threats and surface attack
Review from bubblewrap/flatpak maintainer Simon McVittie: here
Review from security guy like Daniel Micay: here
and thus if any sandboxing tool to be used is Bubblewrap. (full discussion can be found here)
^^^ These are the arguments posted in our forums, i hope only experts to reply on these issues and i hope the replies to be technical and not biased.
(sorry if this is not a bug, but i want to hear your thoughts about it)
ThX!
Note by @kmk3: There are multiple discussions in this repository related to
this topic; see also the following (meta-)discussion, which links to this issue
and others:
The text was updated successfully, but these errors were encountered: