github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #1187] Add missing negator instructions #815

New issue

Closed

opened 2026-05-05 06:53:56 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 06:53:56 -06:00

Owner

Originally created by @cryzed on GitHub (Mar 31, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1187

Currently blacklist and its counterpart noblacklist exist, which are really useful to create modular profiles which can inherit from each other. It would be quite useful if this concept could be generalized to all other instructions where this is not currently possible. Maybe let me explain my use case:

I'm currently (and mostly successfully) attempting to use Firejail to sandbox (i.e. --private=...) all programs that handle untrusted data: for example Firefox, mpv, my image viewer, music player etc. To do this I created a custom profile based on the restrictive default profile (/etc/firejail/default.profile) which includes all blacklist instructions for absolute paths (i.e. system paths), but ignores all others blacklisting directories in the user's home directory, since it's running in a private home anyways. To that end I actually created a small Python script which attempts to parse the default profile and keep my custom "sandbox" profile up-to-date: it's probably not perfect, but it works.

Of course simply sandboxing all applications without a "bridge" to my real data would be pretty useless in most cases, so I further bind mounted my XDG directories in my home folder to a matching folder in /mnt/home-data/ and "whitelist" those directories using noblacklist instructions in the application's profile. I'm explaining all this to make clear that the system has become slightly complex, but adding additional instructions to overwrite/negate previously parsed ones would allow me to keep it at this complexity and modularity.

One use case where this creates issues currently is the following: I have the following _sandbox.profile (created by the script) which is included by all "sandboxed" applications profiles. This works for most applications, however for VirtualBox the following profile is an issue, as you can imagine.

include ~/.config/firejail/_whitelist-documents.profile
include ~/.config/firejail/_whitelist-end.profile
include ~/.config/firejail/_sandbox.profile

_whitelist-documents.profile:

noblacklist /mnt/home-data
noblacklist /mnt/home-data/Documents

_whitelist-end.profile:

blacklist /mnt/home-data/*

According to the default VirtualBox profile, I can only pretty much specify caps.drop all without running into errors. Now I would prefer to not simply include the complete contents of the sandbox profile and modify it accordingly -- it would be much neater if I could overwrite/disable previous instructions just like I can with blacklist/noblacklist. I hope this makes the use-case clear, even for less complex scenarios.

This would also be ideal to design for example a 100% restrictive profile allowing the application to do basically nothing except print to stdout/stderr and access the libraries and CPU which one could then weaken step by step through those negators, instead of doing it the other way around: i.e. more of a whitelist instead of blacklist approach.

PS: If I'm doing something completely insane I would also appreciate some feedback.

Originally created by @cryzed on GitHub (Mar 31, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1187 Currently `blacklist` and its counterpart `noblacklist` exist, which are really useful to create modular profiles which can inherit from each other. It would be quite useful if this concept could be generalized to all other instructions where this is not currently possible. Maybe let me explain my use case: I'm currently (and mostly successfully) attempting to use Firejail to sandbox (i.e. `--private=...`) all programs that handle untrusted data: for example Firefox, mpv, my image viewer, music player etc. To do this I created a custom profile based on the restrictive default profile (`/etc/firejail/default.profile`) which includes all blacklist instructions for absolute paths (i.e. system paths), but ignores all others blacklisting directories in the user's home directory, since it's running in a private home anyways. To that end I actually created a small [Python script](https://gist.github.com/cryzed/22463ffdc2b5ee68ae65b24d701f399b#file-firejail-sandbox-py-L81) which attempts to parse the default profile and keep my custom "sandbox" profile up-to-date: it's probably not perfect, but it works. Of course simply sandboxing all applications without a "bridge" to my real data would be pretty useless in most cases, so I further bind mounted my XDG directories in my home folder to a matching folder in `/mnt/home-data/` and "whitelist" those directories using `noblacklist` instructions in the application's profile. I'm explaining all this to make clear that the system has become slightly complex, but adding additional instructions to overwrite/negate previously parsed ones would allow me to keep it at this complexity and modularity. One use case where this creates issues currently is the following: I have the following [_sandbox.profile](https://gist.github.com/cryzed/47985ed58c890816063a30fad0b66f79) (created by the script) which is included by all "sandboxed" applications profiles. This works for most applications, however for VirtualBox the following profile is an issue, as you can imagine. ``` include ~/.config/firejail/_whitelist-documents.profile include ~/.config/firejail/_whitelist-end.profile include ~/.config/firejail/_sandbox.profile ``` * `_whitelist-documents.profile`: ``` noblacklist /mnt/home-data noblacklist /mnt/home-data/Documents ``` * `_whitelist-end.profile`: ``` blacklist /mnt/home-data/* ``` According to the default VirtualBox profile, I can only pretty much specify `caps.drop all` without running into errors. Now I would prefer to not simply include the complete contents of the sandbox profile and modify it accordingly -- it would be much neater if I could overwrite/disable previous instructions just like I can with `blacklist`/`noblacklist`. I hope this makes the use-case clear, even for less complex scenarios. This would also be ideal to design for example a 100% restrictive profile allowing the application to do basically nothing except print to stdout/stderr and access the libraries and CPU which one could then weaken step by step through those negators, instead of doing it the other way around: i.e. more of a whitelist instead of blacklist approach. PS: If I'm doing something completely insane I would also appreciate some feedback.

gitea-mirror

2026-05-05 06:53:56 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 06:54:03 -06:00

Author

Owner

@cryzed commented on GitHub (Apr 4, 2017):

I just discovered the ignore option for the profiles, is that possibly what I'm searching for? If so, I'm sorry for creating the issue.

@cryzed commented on GitHub (Apr 4, 2017): I just discovered the `ignore` option for the profiles, is that possibly what I'm searching for? If so, I'm sorry for creating the issue.

gitea-mirror commented

2026-05-05 06:54:05 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 9, 2017):

No problem, I'll close it for now.

@netblue30 commented on GitHub (Apr 9, 2017): No problem, I'll close it for now.

gitea-mirror referenced this issue

2026-05-05 10:07:25 -06:00

[PR #815] [MERGED] CVE-2016-7545 fix improvement #3761

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#815

No description provided.

Rows
Columns