Firejail: Firejail worsen security?

[TNTBOMBOM]

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!

[FOSSONLY]

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]

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.

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.

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 every firejail CVE was easily exploited. Please point out a single known firejail vulnerability that was only exploitable under "completely absurd conditions".

It's also not fair to compare Firejail with Flatpak or the underlying Bubblewrap which is used by Flatpak.

We are not comparing firejail with flatpak and bubblewrap is fair to compare to firejail.

But if you strictly consider the question of security, then suid binaries like Firejail and Bubblewrap are basically problematic.

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]

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.

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.

And every firejail CVE was easily exploited. Please point out a single known firejail vulnerability that was only exploitable under "completely absurd conditions".

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.

We are not comparing firejail with flatpak and bubblewrap is fair to compare to firejail.

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.

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.

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]

There are two distinct scenarios:

1. app/service runs inside firejail sandbox
2. app/service runs outside firejail sandbox

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]

In 2017 yes, but now not.

No, it still has large attack surface.

And even if there might be more security holes found in Firejail, Bubblewrap isn't immune against new security holes too.

I never said it was. It's just far less likely for it to have security holes due to its reduced attack surface.

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.

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

A sandbox that is started as root is basically insecure, and would also be a risk in the case of Bubblewrap.

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.

Not really, especially since Bubblewrap is functionally very minimalistic

That's why it's so good.

Less code does not mean that this code offers less attack surface than that of more extensive software.

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 nodbus which are basically just over complicated blacklist rules.

[madaidan]

Firejail significantly reduces attack surface for 1

Sure, it can but firejail's large attack surface makes it far more easier to escape.

The question is if today's desktop linux systems are multi-user focused (with some of them being untrusted).

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.

but merely installing bubblewrap does nothing for scenario 1 unless someone write special wrapper for it with profiles for many specific apps.

That's what I'm planning to do.

[Vincent43]

Sure, it can but firejail's large attack surface makes it far more easier to escape.

Easier than for unsandboxed app? Obviously no. Was there a cve that worked inside sandbox?

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.

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.

That's what I'm planning to do.

Great, please share your code.

[madaidan]

Easier than for unsandboxed app?

No, I meant easier than bubblewrap.

Was there a cve that worked inside sandbox?

Yes.

CVE-2019-12589

CVE-2019-12499

CVE-2017-5940

CVE-2017-5206

CVE-2017-5180

CVE-2016-9016

Yes, however I consider scenario when malware author writes script that will compromise some app and then go for firejail as rather unlikely.

Firejail is a setuid program with large attack surface. Many malware authors would go after it as it's such a vulnerable target.

[Vincent43]

No, I meant easier than bubblewrap.

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.

CVE-2019-12589

It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.

CVE-2019-12499

It works only when firejail is run as root, again it doesn't add additional attack surface on system.

CVE-2017-5940

Exploit need to be run outside sandbox

CVE-2017-5206

It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.

CVE-2017-5180

Exploit need to be run outside sandbox

CVE-2016-9016

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.

Firejail is a setuid program with large attack surface. Many malware authors would go after it as it's such a vulnerable target.

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 :smile: ). 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]

CVE-2017-5940

Exploit need to be run outside sandbox

It doesn't.

https://www.cvedetails.com/cve/CVE-2017-5940/

"which allows local users to conduct sandbox-escape attacks"

CVE-2017-5180

Exploit need to be run outside sandbox

It doesn't.

https://www.cvedetails.com/cve/CVE-2017-5180/

"which allows local users to conduct sandbox-escape attacks"

So to conclude above, none of those cve allowed to raise privileges when run inside sandbox in comparison to unsandboxed case.

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.

Malware authors usually try to target as many users as possible

So they would want to target one of the most popular linux sandboxing programs, firejail.

[smitsohu]

@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).

i hope only experts to reply on these issues and i hope the replies to be technical and not biased.

There are already so many false claims in this thread that I don't know where even to start.

[smitsohu]

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]

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.

[smitsohu]

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 nodbus option. Which is a nice example by the way: Not only is nodbus particularly harmless (I'm honestly curious how this option increases attack surface)... if you don't provide something like nodbus, all you do is putting the burden for doing something wrong on the shoulder of the user.

[smitsohu]

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.

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]

@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

High rate or hole of privilege escalations: references CVEs and Seclist discussion.

Already explained above. We don't really care about the optics.

Firejail bulky code and complexity increases security threats and surface attack

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.

Review from bubblewrap/flatpak maintainer Simon McVittie: here

We don't seem to be very popular with bubblewrap people.

Review from security guy like Daniel Micay: here

He doesn't seem too happy about flatpak/bubblewrap either. From the link:

Really, people just like saying that their preferred software stack is secure, or that open source software is secure, when in reality it's not the case. Desktop Linux is falling further and further behind in nearly all of these areas. The work to try catching up like Flatpak is extremely flawed and is a failure from day 1

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]

Quote @smitsohu https://github.com/netblue30/firejail/issues/3046#issuecomment-555269503

The descriptions are misleading

If the CVE descriptions are misleading, do you have security advisories, summaries or something? Or how do I learn more about these?

[smitsohu]

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-nonewprivs in /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-network switch. Debian enables this one by default since Buster.

[smitsohu]

If the CVE descriptions are misleading, do you have security advisories, summaries or something? Or how do I learn more about these?

@adrelanos No. But the exploit was published, you can find it here

[adrelanos]

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 esc might mean many things? It supposed to mean full privilege escalation from user to root to kernel?

full priv esc from the sandbox means 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?

[M83tUt3]

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]

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]

@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]

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]

What do you think about systemd to check all code of firejail and bubblewrap via fuzzit, coverty, oss-fuzz etc.?

systemd?

[madaidan]

@smitsohu

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!

Nobody has said they weren't fixed. Firejail still has too large attack surface even though you fixed a few vulnerabilities in the past.

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

Do you have a source on bubblewrap also being vulnerable?

@netblue30

Once inside a sandbox - firejail, bubblewrap, or any other seccomp sandbox - you can not exploit any SUID executable present in the system.

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.

Don't use this on enterprise servers, or any other multiuser system. Firejail was built for single-user desktops.

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.

He doesn't seem too happy about flatpak/bubblewrap either.

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.

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.

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

full priv esc might mean many things? It supposed to mean full privilege escalation from user to root to kernel?

No, I mean from user to root.

But since it was run under firejail, the attacker could have escalated to root or kernel privilege?

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

Regarding BPF, Bubblewrap allows any random BPF code from user, which could be questionable.

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 argument

Bubblewrap does not allow application level IP firewalling.

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.

Then Firejail has higher level features like X11 sandboxing

It's easy to do that in bubblewrap and I've done it many times before.

It's easy to compare SLOC counts, but then you should compare which part of that is running privileged and which is sandboxed.

Bubblewrap drops privileges properly.

The major point with Firejail is that it is very easy to setup and has lots of profiles for common applications.

Exactly. Firejail focuses too much on usability and making itself easy to use which increases attack surface substantially.

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.

I've thought of making a wrapper for bubblewrap that makes it easier to use for a while now.

[netblue30]

@M83tUt3

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.

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.

Do I not benefit from running certain applications such as a browser, or obscure pip packages under Firejail?

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]

@FOSSONLY

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.

We tried to remove rarely used features, debug tools and so on. It was about 40% of the code.

On the other hand, the reduction of functionality is not a basic solution for more security.

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]

@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]

The BPF program could be evil while not being invalid.

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.

I don't see how firewalling could increase attack surface (on the contrary), what do you mean?

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]

@madaidan

Nobody has said they weren't fixed. Firejail still has too large attack surface even though you fixed a few vulnerabilities in the past.

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.

Only a side note, the only difference between Firejail and Bubblewrap with regards to CVE-2019-12499 ....
Do you have a source on bubblewrap also being vulnerable?

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]

@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]

@smitsohu

I'm curious, what additional switches in /etc/firejail/firejail.config (to disable functionality) do you think we need?

It's not about any switches. Firejail is not designed with minimal attack surface in mind.

@topimiettinen

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.

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.

Likewise, the firewall filters are installed by Firejail and the application has no control over those.

I never said the application has control over those. The user creating the sandbox does have control over them.

How could they make security any worse?

I've already said. They expose a lot of attack surface.

Also, I don't see what user namespaces have to do with firewalls.

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.

What netfilter code is made available to unprivileged users?

The code that does the firewalling.

[netblue30]

@madaidan

I think we gave you all the information you requested., just read our responses again. I'm closing the discussion for now.

[TNTBOMBOM]

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 :heart_decoration:

[dm17]

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]

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]

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]

What sandbox alternatives do you recommend if I was a political dissident in a tyrannical environment?
Just plain AppArmor?

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

I would advice to look at holistic security solutions like QubesOS however this would need to reinvent the way you use the system.

Security within the VMs is still important when using QubesOS. You should use a strict sandbox inside a VM for defense in depth.

[crocket]

@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]

How are you going to filter dbus? bubblewrap doesn't do dbus filtering.

AppArmor supports fine-grained D-Bus restrictions, or you can use separate users like sandbox-app-launcher does.

Where do I find you for discussing sandbox security?

https://forums.whonix.org/t/system-wide-sandboxing-framework-sandbox-app-launcher/9008/