Firejail: Allow private-dev to accept aditional devices

[ghost]

Currently private-dev create default device whitelist which can't be adjusted. I think it would be good to allow expanding it with additional devices similar as in private-bin option. Example:
private-dev dvb

Above will allow default /dev whitelist + /dev/dvb. It will allow adding private-dev to much more apps which need one or two specific devices. It would be way easier than maintaining app specific device whitelists and more secure than disabling private-dev altogether, see https://github.com/netblue30/firejail/pull/1445 . Also this will lose pressure for adding additional devices to default whitelist, see https://github.com/netblue30/firejail/issues/608

[smitsohu]

I guess that would also allow us to better integrate Yubikey-enabled apps

[SkewedZeppelin]

@smitsohu for Yubikey it'd still require whitelisting hidraw*, unless you could filter using vendor id.

[ghost]

As I understand private-dev hidraw* would be enough.

[startx2017]

Support for dvb is on mainline, give it a try, I don't have a dvb card.

/dev/dvb will be allowed by default in private-dev.

If it is working, I'll add a --notv command (notv in profile files), similar to novideo and nosound.

[ghost]

Isn't better and easier to adjust private-dev? As I stated above it'll eliminate pressure for adding new devices to default list, which 90% apps doesn't ever need and introducing dozens of no3d,novideo,notv, no* options which will clutter profiles?

[smitsohu]

@startx2017 I don't have TV signal in the moment :-) But I can confirm that the DVB device is availabe inside the sandbox, with private-dev enabled.

EDITED: From all media players that have Firejail support currently, it seems VLC, MPlayer, Gnome-MPlayer, SMPlayer, Totem, mpv and Kodi are DVB-capable (one could also count Mediathekview, though that is debatable). Which means that an option notv should go to all other profiles with private-dev.

[netblue30]

Thanks @smitsohu!

Let's go for --notv. I'll add it to all profiles after the current round of merges from @SpotComms.

I'm not too worried about cluttering, we'll clean them later. I think we can collapse several of them into something like "service sound,video,tv,3d" the way we did we "protocol inet,inet6,unix..."

[smitsohu]

@startx2017 Thanks for fixing!

[ghost]

@netblue30

I'm not too worried about cluttering, we'll clean them later. I think we can collapse several of them into something like "service sound,video,tv,3d" the way we did we "protocol inet,inet6,unix..."

My proposition will look exactly like this without inventing new config options: private-dev dri,video,dvb... Also this way private-dev can be an universal option which can be added to every profile as tailoring it to problematic app doesn't need further changing code in firejail to expand whitelist then change code again to provide new no* option and so on...

I don't see the point of creating many new options which purpose is to blacklist one single file. It weakens private-dev as it's default whitelist is getting bigger and bigger, therefore adding it would involve need to add most no* options at the same time to counter this effect. I bet many new profile submissions will miss some of those which means that maintainers would have to constantly monitoring and adjusting new profiles.

Is there something I miss? Why you are reluctant to adjust private-dev instead?

[netblue30]

I don't see the point of creating many new options which purpose is to blacklist one single file.

It is more than a single file. For example --nosound has some files in /dev and also PulseAudio. For --novideo (videocamera) there are files in /dev and they are already taking about doing something similar to PulseAudio, bringing in daemons and sockets. --notv and --no3d are strictly based on /dev but this can also change. Going forward we can also start integrating them with private-bin and private-lib.

Yes, in the short run we'll clutter the profile files, but we'll clean them at some point and collapse all of them on a single line, something like "service sound,video,tv,etc...", or "subsystem sound,video,tv..." to give it a better name. My feeling is we should target subsystems in the profile files instead of individual files - the files are changing all the time. I am looking now at /dev/dvd and /dev/cdrom - it is quite a mess, no two distributions are the same.

Anyway, we can always go back to managing individual files under /dev as you propose, we already have support for /dev under --whitelist command.