[GH-ISSUE #1446] Allow private-dev to accept aditional devices

gitea-mirror commented

2026-05-05 07:14:39 -06:00

Owner

Originally created by @ghost on GitHub (Aug 9, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1446

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

Originally created by @ghost on GitHub (Aug 9, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1446 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

gitea-mirror

2026-05-05 07:14:39 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 07:14:44 -06:00

Author

Owner

@smitsohu commented on GitHub (Aug 9, 2017):

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

@smitsohu commented on GitHub (Aug 9, 2017): I guess that would also allow us to better integrate Yubikey-enabled apps

gitea-mirror commented

2026-05-05 07:14:44 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Aug 9, 2017):

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

@SkewedZeppelin commented on GitHub (Aug 9, 2017): @smitsohu for Yubikey it'd still require whitelisting hidraw*, unless you could filter using vendor id.

gitea-mirror commented

2026-05-05 07:14:46 -06:00

Author

Owner

@ghost commented on GitHub (Aug 9, 2017):

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

@ghost commented on GitHub (Aug 9, 2017): As I understand `private-dev hidraw*` would be enough.

gitea-mirror commented

2026-05-05 07:14:48 -06:00

Author

Owner

@startx2017 commented on GitHub (Aug 9, 2017):

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.

@startx2017 commented on GitHub (Aug 9, 2017): 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.

gitea-mirror commented

2026-05-05 07:14:50 -06:00

Author

Owner

@ghost commented on GitHub (Aug 9, 2017):

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?

@ghost commented on GitHub (Aug 9, 2017): 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?

gitea-mirror commented

2026-05-05 07:14:51 -06:00

Author

Owner

@smitsohu commented on GitHub (Aug 9, 2017):

@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.

@smitsohu commented on GitHub (Aug 9, 2017): @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`.

gitea-mirror commented

2026-05-05 07:14:52 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2017):

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..."

@netblue30 commented on GitHub (Aug 10, 2017): 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..."

gitea-mirror commented

2026-05-05 07:14:55 -06:00

Author

Owner

@smitsohu commented on GitHub (Aug 10, 2017):

@startx2017 Thanks for fixing!

@smitsohu commented on GitHub (Aug 10, 2017): @startx2017 Thanks for fixing!

gitea-mirror commented

2026-05-05 07:14:56 -06:00

Author

Owner

@ghost commented on GitHub (Aug 10, 2017):

@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?

@ghost commented on GitHub (Aug 10, 2017): @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?

gitea-mirror commented

2026-05-05 07:14:58 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 11, 2017):

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.

@netblue30 commented on GitHub (Aug 11, 2017): > 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.

Rows
Columns

[GH-ISSUE #1446] Allow private-dev to accept aditional devices #973