You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is problematic for an administrator to install firejail in a multiuser environment, as there is no way to prevent users from using problematic features (which aren't problematic on a local, single-user computer, usually).
For instance:
interface, ip, ip6 and iprange all allow the user to configure network interfaces;
net lets a user “grab” a new IP on the local network: in some circumstances (network using routable addresses, colocation, ...), this is highly undesirable [0].
The simplest way I can see to handle that is to let the sysadmin specify either a whitelist or a blacklist of features in a dedicated file under /etc/firejail. Special care must be taken to avoid features such as private-etc being used to fool firejail into ignoring those restrictions.
[0] Some providers have trigger-happy automation that would consider it an IP-spoofing attempt and it would lead to the server being immediately shut down.
The text was updated successfully, but these errors were encountered:
I'll have a new firejail version out in a few days. For now you can grab the code from git. The new version fixes this problem by using a run-time configuration file: /etc/firejail/firejail.config. Among other things, it allows the admin to disable networking. This is the link in git: https://github.com/netblue30/firejail/blob/master/etc/firejail.config
Currently, it is problematic for an administrator to install
firejail
in a multiuser environment, as there is no way to prevent users from using problematic features (which aren't problematic on a local, single-user computer, usually).For instance:
interface
,ip
,ip6
andiprange
all allow the user to configure network interfaces;net
lets a user “grab” a new IP on the local network: in some circumstances (network using routable addresses, colocation, ...), this is highly undesirable [0].The simplest way I can see to handle that is to let the sysadmin specify either a whitelist or a blacklist of features in a dedicated file under
/etc/firejail
. Special care must be taken to avoid features such asprivate-etc
being used to foolfirejail
into ignoring those restrictions.[0] Some providers have trigger-happy automation that would consider it an IP-spoofing attempt and it would lead to the server being immediately shut down.
The text was updated successfully, but these errors were encountered: