Firejail vs. Bubblewrap

Hacking Community Hacking
1

After reading a bit on firejail and the issues with symlinks on updates, I was curious if perhaps there might be another way?

Firejail is similar to Flatpak before bubblewrap was split out in that it combines a setuid tool with a lot of desktop-specific sandboxing features. For example, Firejail knows about Pulseaudio, whereas bubblewrap does not.

The bubblewrap authors believe it’s much easier to audit a small setuid program, and keep features such as Pulseaudio filtering as an unprivileged process, as now occurs in Flatpak.

Also, @cgwalters thinks trying to whitelist file paths is a bad idea given the myriad ways users have to manipulate paths, and the myriad ways in which system administrators may configure a system. The bubblewrap approach is to only retain a few specific Linux capabilities such as CAP_SYS_ADMIN , but to always access the filesystem as the invoking uid. This entirely closes TOCTTOU attacks and such.

other ref:

2

i agree to the blacklist thing, but the other limitations are very effective, and i believe in whitelists instead (i only make available the resources the program needs) but the real strength of firejail is to offer an easy way to limit the attack surface through capabilities, cgroups and other kernel features

1 Like
3

like I said, I was just curious as to the logic…I’m a big believer in there is always more to learn

4

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.