The case for firejail over bubblewrap

[crocket]

In 2019, madaidan criticized firejail from the perspective of security and attack surface. However, security is not independent of all other qualities. Security without freedom and privacy is pointless and can easily turn into another tool of control by government and big tech(e.g., secure boot, CPU management engine, proprietary trusted exeuciton environment(TEE), location tracking by "secure" smartphones, ...). Security should serve privacy and freedom.

In theory, firejail offers less security than bubblewrap by exposing a much bigger attack surface in one binary. However, if you take privacy into account, firejail starts winning.

• Firejail supports executing programs in existing network namespaces. Bubblewrap can't. Executing programs in tor network namespace or VPN network namespace can improve privacy greatly.
• Bubblewrap isn't designed to be used directly by users. There is no bubblewrap frontend that is as versatile as firejail. Firejail has profiles for hundreds of programs. Hundreds of profiles enable users to quickly sandbox applications without much effort. By enabling users to quickly sandbox hundreds of applications, firejail improves actualized privacy greatly.
• Arbitrary code execution as the user that runs a large or suspicious program can be as devastating as arbitrary code execution as root because sensitive data are accessible by the user. Firejail often sandboxes applications that have attack surface million times larger than that of firejail. Thus, firejail can reduce net attack surface of a system by allowing users to quickly sandbox hundreds of applications. Firejail increases net attack surface only if it is installed but is not used to sandbox various large programs.

Until a versatile bubblewrap frontend or a better sandboxing platform appears, I think firejail is the best there is for linux desktop computers. I think enterprise servers that don't need to run a lot of applications or don't need firejail's functionalities can be better served by bubblewrap. Even political dissidents can benefit from firejail when they don't want to use whonix or qubes OS.

But, firejail should improve security by delegating privileged operations to small binaries.

[rusty-snake]

I think enterprise servers that don't need to run a lot of applications or don't need firejail's functionalities can be better served by bubblewrap.

If you want to sandbox servers (e.g. dnsmasq, unbound, nextcloud, nginx, ...) just use systemd's native sandboxing features. Or you use SELinux (RHEL) or AppArmor (Debian/Ubuntu/SLE).

But, firejail should improve security by delegating privileged operations to small binaries.

Related: #3412 (comment)

Until a versatile bubblewrap frontend

TBH: I'm working on something but don't expect an alpha before 2022 if at all.

And to mention it, there is bubblejail.

[crocket]

Is SELinux fully configurable with plain text files? The reason that I like qutebrowser is that it is fully configurable with plain text files.

Other web browsers aren't fully configurable with plain text files. Without plain text files, configuration isn't really portable.

It seems to me that SELinux should be configured with commands instead of plain text files.

[crocket]

Systemd is great for sandboxing, especially for system services but not so much for user apps.

If you allow systemd to consume linux, linux will lose configurability just as windows did. Systemd's end goal is to replicate windows model "after" consuming linux. GNOME replicates windows model and is a lot less configurable than something like i3 or Sway. I stay away from systemd by using gentoo linux. Plain text configuration is the best there is for freedom of configuration.

Systemd will gradually take away configuration options because developers know better than users. Loss of configurability won't happen by accident. It will happen with strong intention and strong funding. GNOME didn't lose configurability by coincidence, either. There are an actual philosophy and a long term plan behind companies like RedHat. RedHat intends to extinguish freedom with ample amounts of government subsidies. RedHat is an extension of government which also wants to extinguish freedom.

When you evaluate softwares, you need to also evaluate the end goal of companies behind softwares.

Security without configurability leads to an electronic prison. I'm not going to voluntarily lock myself up in an electronic prison that's being built by RedHat and other organizations that hate freedom.

[topimiettinen]

Is SELinux fully configurable with plain text files?

The policy is a plain text file (mozilla policy). However, it's processed with M4 macros and then compiled into a binary object for loading into kernel. AppArmor is similar. TOMOYO's policy is exactly the same text as what is loaded to kernel and it's possible to read back the policy in the same plain text format from /sys/kernel/security/tomoyo/domain_policy. I don't know about Smack.

Systemd will gradually take away configuration options

This is not true at all, the configuration (plain text files) is pretty much the same as from the start. It's easy to harden services with lots of configuration options using mount namespaces, seccomp and capabilities, i.e. exactly the same tools that Firejail uses. The options are also completely optional and there's a lot of compatibility towards SysV init systems. It's certainly possible to start using systemd with only shell scripts managing the services if you like (even start everything with /etc/rc like sysvinit actually does), but that of course doesn't utilize any hardening possibilities.

[crocket]

How do you actually compare SELinux with AppArmor and other viable alternatives?

I will probably use AppArmor anyway for its simplicity, though.

[topimiettinen]

One way of comparing is to look at the core of the MAC systems. At the bottom, all MACs use LSM interface of the kernel. Some MACs use more hooks than the others, indicating wider set of controls.

Direct links to the MAC LSM hooks:
AppArmor
LandLock: Cred FS ptrace
SELinux
Smack
TOMOYO

Random statistics:

cd security && for d in */; do echo -n $d; grep LSM_HOOK_INIT $d/*.[ch] | wc -l; done
apparmor/69
bpf/3
integrity/0
keys/0
landlock/19
loadpin/3
lockdown/1
safesetid/3
selinux/205
smack/110
tomoyo/28
yama/4

This is of course too simplistic, most people don't need to consider whether the chosen MAC supports Infiniband or SCTP.

[rusty-snake]

In theory, firejail offers less security than bubblewrap by exposing a much bigger attack surface in one binary.

^{MY OPINION! only against direct usage of bwrap:}
... and in reality bubblewrap offers less security than firejail because users need to

• know details of the filesystem and how Linux work or they end up with to broad permissions
• write and compile seccomp filters by them self. A lot users lack the knowledge to do so at all. Furthermore if anybody does this mistakes are much more likely than one implementation review by more users.
• setup xdg-dbus-proxy by them self or they end up with
  A. missing features for some programs (good case)
  B. the biggest sandbox escape vector open.

Give me the next days and I come up with a bigger writing.

[crocket]

If it allows very tight sandboxes, why do we need xdg-dbus-proxy instead of native sandbox mechanisms of dbus?

[crocket]

Why is org.kde.StatusNotifierWatcher unsandboxable? Why are org.gtk.vfs.* helpers unsandboxed?

[rusty-snake]

If it allows very tight sandboxes, why do we need xdg-dbus-proxy instead of native sandbox mechanisms of dbus?

Because xdg-dbus-proxy can be applied by firejail for sandboxes while the native policies can only be done for a whole bus (i.e. admins, distributors and developer should set them up).

Dreams: xdg-dbus-proxy can be used for dynamic filtering like inspecting message content (e.g. a D-Bus firewall).

Why is org.kde.StatusNotifierWatcher unsandboxable?

#4053, to quote the spec:

Each application can register […] Status Notifier Items by registering […] the service org.freedesktop.StatusNotifierItem-PID-ID, where PID is the process id of the application

Guess what happens if you use PID-namespaces and

• two programs have the same PID (in an other namespace)
• you try to setup own (which implies talk) rules

Why are org.gtk.vfs.* helpers unsandboxed?

Ask the developers or use firecfg.py and write profiles for them.

[crocket]

How are you then going to sandbox applications that use StatusNotifierItem?

[rusty-snake]

For applications strictly following the spec (e.g. using KDE/Qt libs):

dbus-user.talk org.kde.StatusNotifierWatcher
dbus-user.own org.kde.*

That's why I created #4510.

[crocket]

I think madaidan's recommendations are quite problematic. He recommends MacOS, windows, and iOS over linux.

MacOS, windows, and iOS don't respect privacy and freedom.

The strongest security doesn't matter if it comes without freedom and privacy. There should be balance.

[rusty-snake]

Well his recommendations are correct. IF you want a maximum of technical security. However if you also want privacy and freedom you have to make trade-offs. And if you aren't an expect in computers, you might have trouble to implement all points.

[crocket]

The thing is that you will be safe in a(n electronic) prison. But, you will not be free to do what you want. Sometimes, guards will come in your prison cell to beat you up or rape you. If you give up freedom for security provided by big tech, you end up losing security in the end. Big tech security measures have backdoors for guards. Backdoors nullify security. Security with backdoors only offers illusion of security.

[SkewedZeppelin]

I strongly disagree with many of their points and can't stand how many people constantly point to them and parrot them.

That isn't to say a lot of what they say isn't correct.

People just putting a square box in a round hole even if what they need is a triangle.

[topimiettinen]

It's interesting to search for 'how to harden windows', 'how to harden mac' and 'how to harden android'. The suggestions are at very basic level: secure passwords, regular backups etc. Why? Because the system administrators actually can't do much to improve the security. Not because there's nothing to harden (the opposite) but because the OS is very opaque and it doesn't provide good means to harden its components or lock down 3rd party apps. With Linux the sky is the limit.

For example, many phishing attacks need that Outlook can write email attachments to an insecure location which allows the user to execute kittens.jpg.exe files. If you buy the Ultimate/Enterprise version, AppLocker can disallow execution. This still doesn't help if the problem is that attachment cutepuppies.mov contains an exploit against MOV player. If there was a MAC system (or Firejail equivalent) for Windows, it could be able to contain the exploit. Android uses SELinux and the security model seems to be good but it's pretty hard to know what's happening inside.

[curiosityseeker]

Well his recommendations are correct.

I don't think so. He generalizes too much and makes sweeping arguments. For example, here he says that the Linux "kernel is decades behind in exploit mitigations" and proves that with a document published in 2012 - neglecting many improvements since then partially adopted from grsecurity by the work of the Kernel Self-Protection Project.