mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3046] Does firejail worsen security? #1912
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1912
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Nurmagoz on GitHub (Nov 18, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3046
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:
@FOSSONLY commented on GitHub (Nov 18, 2019):
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.
@madaidan commented on GitHub (Nov 18, 2019):
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.
@FOSSONLY commented on GitHub (Nov 18, 2019):
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.
@Vincent43 commented on GitHub (Nov 18, 2019):
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.
@madaidan commented on GitHub (Nov 18, 2019):
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 https://github.com/netblue30/firejail/issues/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 https://github.com/containers/bubblewrap/issues/317#issuecomment-498294290
Meanwhile firejail is constantly adding attack surface with pointless options like
nodbuswhich are basically just over complicated blacklist rules.@madaidan commented on GitHub (Nov 18, 2019):
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.
@Vincent43 commented on GitHub (Nov 18, 2019):
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.
@madaidan commented on GitHub (Nov 18, 2019):
No, I meant easier than bubblewrap.
Yes.
CVE-2019-12589
CVE-2019-12499
CVE-2017-5940
CVE-2017-5206
CVE-2017-5180
CVE-2016-9016
Firejail is a setuid program with large attack surface. Many malware authors would go after it as it's such a vulnerable target.
@Vincent43 commented on GitHub (Nov 18, 2019):
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.
@madaidan commented on GitHub (Nov 19, 2019):
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.
@smitsohu commented on GitHub (Nov 19, 2019):
@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.
@smitsohu commented on GitHub (Nov 19, 2019):
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.
@madaidan commented on GitHub (Nov 19, 2019):
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.
@smitsohu commented on GitHub (Nov 19, 2019):
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
nodbusoption. Which is a nice example by the way: Not only isnodbusparticularly harmless (I'm honestly curious how this option increases attack surface)... if you don't provide something likenodbus, all you do is putting the burden for doing something wrong on the shoulder of the user.@smitsohu commented on GitHub (Nov 19, 2019):
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 :)
@netblue30 commented on GitHub (Nov 19, 2019):
@madaidan
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.
@TNTBOMBOM
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.
@adrelanos commented on GitHub (Nov 19, 2019):
Quote @smitsohu https://github.com/netblue30/firejail/issues/3046#issuecomment-555269503
If the CVE descriptions are misleading, do you have security advisories, summaries or something? Or how do I learn more about these?
@smitsohu commented on GitHub (Nov 19, 2019):
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
force-nonewprivsin /etc/firejail/firejail.config (maybe we could have it as a compile time option, too).The problem is that with NO_NEW_PRIVS you cannot sandbox all apps any more. For example, it breaks Chromium on Debian, as Chromium relies on a setuid binary for its own sandboxing.
You can also take a look at other switches in /etc/firejail/firejail.config, for example the
restricted-networkswitch. Debian enables this one by default since Buster.@smitsohu commented on GitHub (Nov 19, 2019):
@adrelanos No. But the exploit was published, you can find it here
@adrelanos commented on GitHub (Nov 19, 2019):
Trying to wrap my head around this. First, terminology.
First @madaidan was the first one to say
full priv esc from the sandbox.Then @smitsohu said
full priv esc.full priv escmight mean many things? It supposed to meanfull privilege escalation from user to root to kernel?full priv esc from the sandboxmeans suppose an exploit running in a firejail sandbox (run as user, not root, I suppose) has lead to root or kernel level access?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?
@ghost commented on GitHub (Nov 19, 2019):
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:
Also a genuine question: I'm on a single user system. If something malicious runs outside of a sandbox under my own user I consider myself pwned anyway as I'm on X and it's standard desktop linux simply doesn't protect you in this case. Do I not benefit from running certain applications such as a browser, or obscure pip packages under Firejail?
@topimiettinen commented on GitHub (Nov 19, 2019):
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.
@smitsohu commented on GitHub (Nov 19, 2019):
@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).
I don't think this is the right place to discuss the semantics of "sandbox escape". If there is desire for further discussion in that regard, let's do it in a separate issue.
@FOSSONLY commented on GitHub (Nov 19, 2019):
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.?
@Vincent43 commented on GitHub (Nov 19, 2019):
systemd?
@madaidan commented on GitHub (Nov 19, 2019):
@smitsohu
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?
@netblue30
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.
@adrelanos
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.
@topimiettinen
No, that's not true. If you try to use anything other than a valid seccomp filter, it will give an error:
bwrap: prctl(PR_SET_SECCOMP): Invalid argumentThat'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.
@netblue30 commented on GitHub (Nov 19, 2019):
@M83tUt3
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.
@netblue30 commented on GitHub (Nov 19, 2019):
@FOSSONLY
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.
@topimiettinen commented on GitHub (Nov 19, 2019):
@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?
@madaidan commented on GitHub (Nov 19, 2019):
So what do you expect a malicious user to do? Run their own program with a seccomp filter? What will that get? How is it evil?
Bubblewrap only accepts valid seccomp filters. I don't see how that can be abused at all.
You're exposing a ton of netfilter code to unprivileged users which is only meant for root. Read the many discussions on why user namespaces are a bad idea.
@smitsohu commented on GitHub (Nov 19, 2019):
@madaidan
I'm curious, what additional switches in /etc/firejail/firejail.config (to disable functionality) do you think we need? We can add more, in many cases it is quite simple to do. Users and distributions can enable and disable them how they please.
There is CVE-2019-8308 which was assigned to Flatpak, but Bubblewrap is the affected component. There is also a discussion on the Bubblewrap bug tracker.
@topimiettinen commented on GitHub (Nov 19, 2019):
@madaidan On the kernel side, earlier there was expectation to allow loading of BPF code by unprivileged apps one day. Now, in light of Spectre/Meltdown types of attacks, it seems that running untrusted byte code in kernel will probably never be allowed (see LWN article). The problem is that the malicious BPF code could use bugs in speculative execution to read kernel memory etc. Firejail compiles all BPF by itself so the contents is known.
Likewise, the firewall filters are installed by Firejail and the application has no control over those. How could they make security any worse? Also, I don't see what user namespaces have to do with firewalls. What netfilter code is made available to unprivileged users?
@madaidan commented on GitHub (Nov 20, 2019):
@smitsohu
It's not about any switches. Firejail is not designed with minimal attack surface in mind.
@topimiettinen
Are you intentionally ignoring things I've said? Bubblewrap doesn't execute random BPF code. It only loads valid seccomp filters.
Please show how you can exploit Spectre with just a seccomp filter. Because I'd love to see it.
If you have actual concerns, raise them on bubblewrap's github repo rather than spreading FUD here.
I never said the application has control over those. The user creating the sandbox does have control over them.
I've already said. They expose a lot of attack surface.
Network namespaces allow you to configure iptables inside the namespace. User namespaces allow you to create network namespaces unprivileged therefore exposing tons of netfilter administration code to unprivileged users.
The code that does the firewalling.
@netblue30 commented on GitHub (Nov 20, 2019):
@madaidan
I think we gave you all the information you requested., just read our responses again. I'm closing the discussion for now.
@Nurmagoz commented on GitHub (Nov 20, 2019):
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 💟
@dm17 commented on GitHub (May 28, 2020):
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.
@crocket commented on GitHub (Oct 29, 2020):
Sorry for chiming in late.
@madaidan What sandbox alternatives do you recommend if I was a political dissident in a tyrannical environment?
Just plain AppArmor?
@Vincent43 commented on GitHub (Oct 29, 2020):
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.
@madaidan commented on GitHub (Oct 30, 2020):
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.
@crocket commented on GitHub (Oct 31, 2020):
@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?
@madaidan commented on GitHub (Oct 31, 2020):
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/
@crocket commented on GitHub (Sep 9, 2021):
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.
@dm17 commented on GitHub (Sep 9, 2021):
I have good news for you :) https://github.com/Eloston/ungoogled-chromium
And more good news: https://grapheneos.org/
@crocket commented on GitHub (Sep 9, 2021):
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.
@dm17 commented on GitHub (Sep 9, 2021):
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
You can prevent any app from having GPS access, unless it requires it to run - but then that is your choice to allow it.
@crocket commented on GitHub (Sep 9, 2021):
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.
@rusty-snake commented on GitHub (Sep 9, 2021):
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).
@SkewedZeppelin commented on GitHub (Sep 9, 2021):
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.
@crocket commented on GitHub (Sep 10, 2021):
Anyway, the point is
@dm17 commented on GitHub (Dec 6, 2021):
Anyone have a security comparison for running browsers in flatpak vs firejail vs podman vs docker (non-root)?
@crocket commented on GitHub (Dec 7, 2021):
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.
@SergSel2006 commented on GitHub (Mar 10, 2025):
Well, I might be very late to the party, but "large attack surface" for me is nonsense in that context of firejail. Yes, we have some bulky code, but we need it to harden more bulky code from OS itself. Don't you think that kernel with its hudreds thousands lines of code does not have wide attack surface? Don't you think that some browser has ability to run or at least make you to run some malicious code, that is more likely to exploit endless vulnerabilities varying from some suid programs like sudo to the kernel, systemd or libpam themselves? This then needs to be adressed, but it magically does not the problem now - it is a job of firejail to cover big amount of that vulnerabilities and keep your data safe from attackers with extensive amount of finely-tuned profiles, sandboxing most of the applications that attackers could come from, making life worse for them.