Hi Alain, > Firejail being a setuid executable provides regular users root powers to > bypass > system settings. > I think it's a problem for an official Debian package to automatically > grant regular users that much power without root having actively granted it > (root might not fully appreciate the powers granted to regular users simply > by installing this enhanced security package).
I think the most common use case for firejail is a single user machine, where
the administrator is also the regular user, and it is used to limit what
applications can do on the system.
On multi-user systems the administrator needs to be more careful in general
what is installed and how it is configured.
By installing firejail its functionality is automatically/actively granted,
as that is the expected behavior (like 'ping' works out of the box even for
unprivileged users when it is installed).
> Perhaps Firejail could be installed by default without the SUID bit set, and
> leave it up to root to actively decide if they want to turn it on.
It is documented in README.Debian how administrators can change the SUID
permission for only a specific group (or completely remove it).
> Example:
> root sets up system firewall (simple example here, block all outbound):
> # nft add table ip filter
> # nft add chain ip filter OUTPUT "{ type filter hook output priority 0;
> policy drop; }"
> regular user tries:
> $ wget http://www.google.com # fails, as expected due to firewall rules
> $ firejail --net=enp6s0 --noprofile wget http://www.google.com # works!
> regular user is able to bypass all system firewall rules
I'm not that familiar with nftables, but I can see that this might be
unexpected.
Is it possible to set up rules that apply to all network namespaces?
Because for other programs (like containers) using network namespaces those
rules will probably also not apply.
> Please add/install Firejail with the empty file /etc/firejail/firejail.users.
> At least for versions 0.9.54 and up this will allow root to use Firejail and
> provide users with an informational message as to how they can, if indeed
> they are superusers, add themselves to this file in order to use Firejail.
> Otherwise Firejail assumes all users have superpowers.
> If root wants all users to use Firejail, they can then actively delete
> /etc/firejail/firejail.users; I think this is better than passively granting
> all users superpowers when the package is installed.
I have added an entry to NEWS.Debian for 0.9.54 that informs the administrator
about firejail.users.
As mentioned I think that the expected default behavior is that firejail
works after installation. If users upgrade from stretch to buster and firejail
suddenly no longer works, many would consider it a regression.
> For example (and this is another example of an issue with the default): using
> Firejail any user can join any control group using the --cgroup option,
> therefore overriding certain system controls; the config file does not (at
> this time) provide means to limit this.
Missing configurability for that feature is something that can be implemented.
I will suggest it to upstream.
And then it can maybe get disabled by default.
Kind regards,
Reiner
signature.asc
Description: PGP signature
