Firejail: more gradual control over supplementary groups

[dkavlakov]

The set of global Firefox-specific settings imported in the latest palemoon.profile includes a "nogroups" line, that prevents group-based device permissions from working and leaves Palemoon without access to sound when ALSA is used. Unlike Firefox there is no forced Pulse Audio dependency in Palemoon (including the future 29 series) and it's profile should allow ALSA sound to be used.

[chiraag-nataraj]

So I think the problem is that in the _most common_ usecase, nogroups provides some additional security. Removing it by default when it works for most people (and provides additional security) doesn't make much sense imo. At the same time, I recognize that it screws over people who are currently using ALSA (and will continue to do so). The problem is that nogroups doesn't _just_ allow ALSA to be used, right. It could enable other things which are far more nefarious. If you can document which specific groups are needed (by default, anyway), we might be able to bring in an --enable-alsa flag (and corresponding enable-alsa profile option) so that you can get ALSA sound back without having to disable nogroups.

[netblue30]

@dkavlakov: can you run groups in a terminal, something like this:
$ groups netblue tty sudo autologin

It could give us an idea what we need to add by default.

[dkavlakov]

lp cdrom floppy tape audio dip video plugdev users netdev lpadmin scanner kvm sambashare wireshark vboxusers bluetooth

This is a pretty typical example of the pre-systemd-takeover Debian group permissions model.

Is it security risk? It may become in case of serious misuse of the filesystem group permissions. Is it less secure than your current settings? No! Right now to have sound in Palemoon and Chromium one is supposed to install huge amount of bloatware that includes even an additional, self-sufficient privilege elevation system, managed by huge set of policies, written by multiple third parties . Getting rid of this _realy_ does provide additional security.

[edit] Ok, looking at the "sudo" group membership in the upper example i am forced to agree that with sufficient amount of Ubuntu in the mind one can easily turn group permissions into a threat. This however also proves that having more installed packages with the word "security" in their description (like sudo in the example) does not necessary give you more security.

[chiraag-nataraj]

@dkavlakov
I hope you realize that pulseaudio is separate from systemd, was adopted well before systemd, and is a completely separate project. The fact that Lennart was a huge force behind both is the _only_ thing that connects the two.

That being said, yes, pulseaudio (like most programs on the "modern" desktop) is not designed with security in mind. dbus is a huge security issue. But this is nowhere _near_ an issue unique to pulseaudio or dbus. Most programs don't sandbox themselves. Many system daemons run as root or install SUID executables. Indeed, I would posit that systemd (love it or hate it) has made some of these issues _better_ in that it's exposed some of the same technologies that firejail uses (such as namespaces) in a way such that some distributions and projects have adopted stricter defaults than they were doing under sysvinit. Socket activation means that systemd can set up the sockets and pass them to the program (which means the program no longer needs to run as root just to set up sockets). The same is true for things like temporary directories. So even if many programs aren't taking advantage of it right now, these features mean that they _can_ take advantage of it in the future. Further, the drop-in system ensures I can add stricter defaults to my system (as I have done with several daemons) without having to futz around with the files installed by the system (ensuring I don't need to do manual merging of changes on upgrade).

If you're going to shit on systemd and pulseaudio, at least stick to the facts. I'm neutral on systemd (I like some aspects, but dislike others) and pulseaudio, but I can't stand this mindless hatred when some of these features are objectively a good thing in that they lead to more secure defaults and fewer programs running as root. That is _unquestionably_ a good thing.

[Edit] Also, I literally have most of the same groups in my user, and I'm running a pure systemd system:

$ groups
chiraag tty disk dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner kvm boinc

[chiraag-nataraj]

@netblue30 I think this is doable, but I'm not quite sure exactly how to go about adding this. I think having a --groups= predicate on the command-line and a groups predicate in profiles would be useful. It could retain only those groups while cleaning everything else and would provide a setting other than the binary on/off that we have right now.

[chiraag-nataraj]

--groups=none or groups none could function equivalently to the current --nogroups and nogroups options we have right now.

[glitsj16]

@rusty-snake Did you mean 'gradual' control?

[rusty-snake]

sure, thk

[Leebre]

Hi, I am a new user to firejail. I like it a lot and was going to make a suggestion related to this, but saw this existing issue. Another example from my own use is Skype - it needs access to both the audio and video groups in order to make video calls. So, it won't work correctly with the --nogroups option enabled.

Is it possible for a future release that the groups you want to be available in the sandbox could be specified? --nogroups seems a bit 'all-or-nothing'.

I guess a workaround would be to create another user with more restrictive group permissions and su to them first. But that might lead to difficulties if you need to access anything in the first user's $home directory.

[jonleivent]

@Leebre

I guess a workaround would be to create another user with more restrictive group permissions and su to them first. But that might lead to difficulties if you need to access anything in the first user's $home directory.

I use the "workaround" you describe for other reasons, but I think it is very much worth the effort to do this for the extra security it brings. The "separate users from each other" security model is built into Linux and very well tested and adhered to, so, if you have the Linux know-how to use it, why abandon it just because we have sandboxing these days? Firejail sandboxing without user separation is convenient and easy to set up - and this is firejail's chief benefit over other techniques - but if you can combine multiple techniques to get additive security, go for it.

To deal with access to the first user's home dir, I have the first user be a member in each auxiliary user's group. That way I can selectively enable access, and keep track of who can access what very easily.

As for the audio (and video) issues vs. security, I would love to see firejail implement bridges for these - much the same as it has the ability to bridge network and X11.

[Leebre]

@jonleivent thanks for your advice on this. I agree, it does make sense to use the existing Linux user/group privileges as well as firejail, so I will give that a try. Still, more granular control of group permissions within firejail might be something worth considering for future development.

[jonleivent]

@Leebre I agree with having detailed control over group permissions. There are popular apps, for instance virtualbox, that require certain group permission, and it would be nice to drop all unnecessary group permission while whitelisting the necessary ones.

[topimiettinen]

udevd has uaccess rules, which are used by systemd-logind (maybe also elogind) to change ACLs of the devices (audio, video or cdrom). When a user logs in, the ACLs give access to the devices and the ACLs are removed on logout. This is safer than the older method of using special groups to give access, because once the group rights are given, the user could keep them forever by making a setgid executable. Also, a remote user could use the groups to mess remotely with locally logged in user.

But the group method is still used for other purposes, so the selective groups would be nice. One (a bit theoretical) catch is that the group membership could be used to limit access (g=rx vs o=rwx), but since we allow dropping all groups it's already broken.

[yardenac]

Agreed, granular group settings should be a no-brainer. The overlap between nogroup and noroot are confusing and unnecessary, and this would solve both problems.