On Sun, Jan 27, 2019 at 09:28:56PM +0000, Alain Ducharme wrote: > To be clear: I don’t have a problem with Firejail being a setuid executable > (perhaps a little trepidation ;-), I have an issue with the default broad > powers granted to unprivileged users with the install of the Firejail package.
Understood. > Even on a single user system, the basic security model is: privileged root is > used to configure / set system controls and limits. End user applications > are then run unprivileged, unable to change or override these. > > Installing something like ping (no longer using setuid but caps) does not > allow an unprivileged user or application to override system security > settings like the netfilter firewall, or control groups, or add new network > interfaces / MAC addresses / ip addresses to your network. Yet, by default, > installing the Firejail package enables this for all unprivileged users / > applications. Installing ping also grants users privileges that they would not have otherwise. But I agree that the impact of firejail is much bigger, and the scope might be larger than most administrators think. > Users installing Firejail may not always run everything in a Firejail. I can > imagine an end-user application unable to reach the internet (to phone home, > run a server, etc.) due to the presence of a system firewall could look to > exploit Firejail using --noprofile --net to do whatever it wants on the LAN / > WAN / Internet. > > > Is it possible to set up rules that apply to all network namespaces? > I do not believe this is possible; each network namespace has its own > netfilter rules. > > Because for other programs (like containers) using network namespaces those > > rules will probably also not apply. > Only root can create network namespaces (containers typically use privileged > daemons). I’m not aware of unprivileged user launched containers allowing > the equivalent of Firejail’s --noprofile combined with --net, --mac, --ip (or > even --cgroup) in user space. I have changed the default in firejail.config and enabled "restricted-network" as you suggested (in 0.9.58-1). > > Missing configurability for that feature is something that can be > > implemented. > > I will suggest it to upstream. > Good idea, thanks. It has already been implemented by upstream [0]. I will cherry-pick it into the Debian package and disable the cgroup feature by default in the next days. > Whatever you decide is fine with me. Maybe people who install packages do > read the notes and README. Installing any package or software does present > some risk, more so a setuid one. And perhaps (I don’t know) most users would > want / expect the behavior of the default configuration? Perhaps most users > don’t configure firewalls on their systems!? :-/ I was just hoping to > minimize exposure to unexpected security holes, or at least raise awareness > of them, for future installers. Thanks for your suggestions and sharing your concerns. I want to keep it mostly usable after it is installed without the need to figure out why something is not working and requiring additional setup by root. From my impressions on the upstream bug tracker, many users are not really power-users, but just want to easily improve their security. But I'm fine with changing defaults of features that are less used or have some other negative impact on security. Kind regards, Reiner [0] https://github.com/netblue30/firejail/issues/2371
signature.asc
Description: PGP signature
