Firejail vs SELINUX

[firejailaddssecuirty]

A long time back while I was using Ubuntu I tried learn how to create how to create apparmor profiles. Back then firejail didn't exist. So I have a rough idea how apparmor works. I had used Fedora which comes with selinux by default but I never tried to learn selinux.

Q) How is selinux different in comparison to firejail ? I mean for example the default firejail profile for Firefox restricts FF's access to the ~/Downloads folder only so FF don't have access to other data in user's home. Does selinux do the same ?

I am using Arch which doesn't have selinux or apparmor so I can't experiment and frankly I am not sure if I should replace Arch with Fedora just for selinux.

[glitsj16]

I am using Arch which doesn't have selinux or apparmor so I can't experiment and frankly I am not sure if I should replace Arch with Fedora just for selinux.

Apparmor doesn't come as a 'regular' package you'd install on Arch Linux. All officially supported Linux kernels have AppArmor available the OS by default, you just need to enable it via kernel params. See this wiki page for details. I've been using it for a while now in combination with Firejail. It works, but the main gripe IMO is that not many apparmor profiles get installed by default. As you have experience in creating those I think you'll be settling in fine once you've enabled apparmor support on your Arch Linux machine(s).

[topimiettinen]

This is not off topic, so I edited the title and removed '[OFF TOPIC]'.

There's previous discussion in #4522 about relative merits of various approaches (bubblewrap, AppArmor, SELinux), it may be good to read that thread also.

Firejail uses the methods provided by Linux kernel for sandboxing: seccomp, namespaces (mount, net, pid) and capabilities. SELinux TE rules can also limit access to file system, network and capabilities (and much more) but there's no equivalent to seccomp. Seccomp is very powerful but there are limits what it can control (because pointers to structures or strings can't be dereferenced). SELinux as a MAC system doesn't concern too much about UIDs, which is a DAC concept. There's UBAC though. SELinux is much more fine grained (for example, access to file descriptors passed by the parent process can be controlled) and there are lots of ways to control the system. Not all are very interesting in typical systems, like Infiniband or strange network protocols.

Exhaustively checking all TE rules for the browser can be difficult due to indirections like attributes. As for the ~/Downloads, it is labeled as xdg_downloads_t, so there can be TE rules to control access to it. The rules can be examined with sesearch -t xdg_downloads_t -A. For example, rules for Chrome are on my system:

allow chromium_t xdg_downloads_t:dir { add_name create getattr ioctl link lock open read remove_name rename reparent rmdir search setattr unlink write };
allow chromium_t xdg_downloads_t:file { append create getattr ioctl link lock map open read rename setattr unlink write };
allow chromium_t xdg_downloads_t:lnk_file { create getattr ioctl link lock read rename setattr unlink write };

Notably there are no rules which would allow executing the downloaded files. Other domains can't do it either since sesearch -c file -p execute -t xdg_downloads_t -A and sesearch -c file -p execute_no_trans -t xdg_downloads_t -A don't show anything. There could be other rules though.

If the kernel provided equivalent access control methods to user applications as it provides now to SELinux with LSM hooks, I'm pretty sure we would try to use them all in Firejail. Beefing up seccomp so that the BPF code could access all system call parameters and call lots of kernel functions, would also allow much better control, but this would introduce other problems. Firejail could put the sandboxed process inside a VM with a Firejail nanokernel which could easily intercept system calls without restrictions, but it could be lot of work. It's not impossible, I think gVisor does that.

It's entirely possible to use SELinux and Firejail, they complement each other nicely. With AppArmor there seems to be (or there were earlier) some kind problems so it's not recommended.

[firejailaddssecuirty]

Someone should create a website and offer rules for selinux. Just so that you understand what I mean this is a website I found which offers rules for Liinux's iptables & BSD's PF https://imaprettykitty.com/wof/.

[topimiettinen]

Someone should create a website and offer rules for selinux. Just so that you understand what I mean this is a website I found which offers rules for Liinux's iptables & BSD's PF https://imaprettykitty.com/wof/.

That site translates simple rules to more complex rules used by various tools (except for NFT...). SELinux rules aren't actually very complex (allow type1 type2:class3 { permission1 permission2 }) but the system as whole is baroque with M4 macros and type attributes. I don't know if that kind of translation could be performed. For example, a file can have only one type (or label), like xdg_downloads_t for all files in ~/Downloads. Then it's not possible to make rules which apply only to '*.jpg' there, unless the type is changed to something else and then there should be rules which combine rules (by addition or subtraction?) for xdg_downloads_t and those for the jpegs. Getting from the raw rules level back to M4 level may be difficult. Then the SELinux rules for Fedora aren't the same as rules for Debian, so the website would have to adjust for the differences. In SELinux the rules can only allow something and once something is allowed, it can't be denied anymore (there is no reversing 'deny' rule).

It's also possible to replace SELinux rules just for one module (for example Chrome or Firefox) and create custom rules from scratch. It's not so easy but the result can be much tighter than the default rules.

[netblue30]

The guys from Bind DNS server at ISC did a series of webinars comparing SELinux, AppArmor, Firejail, and the sandbox in SystemD. They talk from a server perspective, not from a desktop app perspective. They say there is an overlap of about 80% among the four of them.

Link for AppArmor/Firejail/SystemD presentation: https://www.youtube.com/watch?v=Cez-RkSQEHY - the conclusions are at 39:48. SELinux is discussed in the previous webinar.

[topimiettinen]

I'd add that 80% could be maybe said for relevant sandboxing features. SELinux is much more comprehensive and fine grained than the others, but also a lot of stuff it covers isn't interesting in general (like obscure network protocols).

The picture also is very different if the equivalents of Firejail's profiles are counted (not fully accurate):

find firejail.git/etc/profile-* -name '*.profile' | wc -l
1176 # Good Stuff. One file for each program
find refpolicy.git/policy/modules -name '*.te' | wc -l
392 # Some SELinux modules are for obsolete or proprietary corporate SW. One module can cover several programs
find apparmor.git/profiles -name 'bin.*' -o -name 'sbin.*' -o -name 'usr.*' | wc -l
114 # One file for each program but there are also variant configurations
find systemd.git/units -name '*.service*' | wc -l
94 # For systemd's own units. One file for each service

Libseccomp project doesn't provide any profiles at all, but of course Firejail and systemd use it extensively. For systemd the situation is actually probably the best or at least much better than the number 94 would indicate, since most projects provide the service files themselves instead of 3rd parties. I think there are no customized and up-to date rulebooks for other MAC systems (Landlock, Smack, TOMOYO).

With AppArmor and TOMOYO it's relatively easy to generate any missing profiles locally. With SELinux, there's ausearch -ts boot | audit2allow -M module (or journalctl -b | audit2allow -M module) which can give good rule suggestions but it can't update or merge changes to previously existing modules. Like Firejail, systemd configuration is a bit trial and error (though years ago I made topimiettinen/systemd-settings-generator to generate service unit files automatically, probably bitrotten), but systemd-analyze security is nice.