[GH-ISSUE #641] Idea: Adaptive file access rights

gitea-mirror commented

2026-05-05 05:52:52 -06:00

Owner

Originally created by @Unrud on GitHub (Jul 22, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/641

Problem

Most applications need access to files that can be scattered everywhere in the user's home directory or on external media. E.g. an PDF viewer needs read access (and possible write access to add annotation etc.) to the whole home directory and /media to work correctly. Same goes for web browsers, which should be able to read everything for uploads etc.

Existing solutions

AppArmor and SELinux can mitigate this to some extent by allowing the PDF viewer to only access PDF files. In case of the web browser this doesn't help.
Probably the best solution is to have an service outside of the sandbox, which applications ask to open files and then passes file descriptions back into the sandbox. Unfortunately this requires adapting all applications.

Proposed solution

The core idea is to use a custom FUSE file system which is mounted inside the sandbox and acts as a proxy to the real file system and a simple set of rules to control file access.

Configuration directives could be something like adaptive-home, which mounts the FUSE file system on /home and represents the real /home as a proxy or something like adaptive ${DOCUMENTS} which does the same for custom folders.

This is accompanied by a rule set that controls file access. With this rules it should be possible to control which files the application can always access and the files that can be accessed after the user was asked.
Configuration directives could be something like adaptive-rule-read-only *.ext and adaptive-rule-read-write globbing/*/pattern/** for files that are directly accessible.
If the applications tries to open some file in the FUSE file system which matches the patterns from adaptive-rule-read-only-ask *.ext or adaptive-rule-read-write-ask *.ext a dialog box gets shown to the user and the IO operation only succeeds if the user allows it.
It would be also possible to only list files to the application that are matched by any of the rules.

The dialog boxes will annoy the user, I have thought of a few ways to keep there amount to a minimum or in some cases eliminate the need for them altogether:

Firejail could search the arguments of the application for file names and automatically grant access to them.
- Example: firejail pdf-viewer test.pdf is started from a file explorer and the profile contains the rule adaptive-rule-read-only-ask *.pdf. Maybe users will stop using integrated open dialogs and always open files via file explorers.
- Example: firejail qpdf --linearize in.pdf out.pdf is started in a terminal.
Add configuration directives to automatically grant access to associated files, after the user has granted access to some file. Something like adaptive-rule-read-write-extra ${FILENAME}.lock or adaptive-rule-read-only-extra ${DIRNAME}/*.jpg (e.g. an image file is opened by an image viewer and the user wants to browse all images in the same folder).
The profile authors should carefully balance between automatically granting access rights to some kind of files and explicitly asking the user.
- Example: It might be okay for a PDF viewer to read all PDF files, but the user should be asked if it tries to write to them
- Example: A web browser can always write to files in ~/Downloads, but other files are denied without explicit permission by the user.

A configuration file could look like this:

adaptive-home
adaptive /media

# Example for LibreOffice
adaptive-rule-read-only-ask *.jpg *.jpeg *.png *.svg # Files that can be included into documents
adaptive-rule-read-write-ask *.odt *.ods *.pdf
adaptive-rule-read-write-extra ${FILENAME}.lock

# Example for PDF viewer, which can read all PDF files without asking the user
adaptive-rule-read-only *.pdf
adaptive-rule-read-write-ask *.pdf

# Example for MonoDevelop
adaptive-rule-read-write-ask *.sln # Main file of a project
adaptive-rule-read-write-extra ${DIRNAME}/** # Automatically allow access to the whole project

What do you think of this idea? Have I overlooked some problem? Was it already proposed?

Originally created by @Unrud on GitHub (Jul 22, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/641 **Problem** Most applications need access to files that can be scattered everywhere in the user's home directory or on external media. E.g. an PDF viewer needs read access (and possible write access to add annotation etc.) to the whole home directory and `/media` to work correctly. Same goes for web browsers, which should be able to read everything for uploads etc. **Existing solutions** AppArmor and SELinux can mitigate this to some extent by allowing the PDF viewer to only access PDF files. In case of the web browser this doesn't help. Probably the best solution is to have an service outside of the sandbox, which applications ask to open files and then passes file descriptions back into the sandbox. Unfortunately this requires adapting all applications. **Proposed solution** The core idea is to use a custom FUSE file system which is mounted inside the sandbox and acts as a proxy to the real file system and a simple set of rules to control file access. Configuration directives could be something like `adaptive-home`, which mounts the FUSE file system on _/home_ and represents the real _/home_ as a proxy or something like `adaptive ${DOCUMENTS}` which does the same for custom folders. This is accompanied by a rule set that controls file access. With this rules it should be possible to control which files the application can always access and the files that can be accessed after the user was asked. Configuration directives could be something like `adaptive-rule-read-only *.ext` and `adaptive-rule-read-write globbing/*/pattern/**` for files that are directly accessible. If the applications tries to open some file in the FUSE file system which matches the patterns from `adaptive-rule-read-only-ask *.ext` or `adaptive-rule-read-write-ask *.ext` a dialog box gets shown to the user and the IO operation only succeeds if the user allows it. It would be also possible to only list files to the application that are matched by any of the rules. The dialog boxes will annoy the user, I have thought of a few ways to keep there amount to a minimum or in some cases eliminate the need for them altogether: - Firejail could search the arguments of the application for file names and automatically grant access to them. - Example: `firejail pdf-viewer test.pdf` is started from a file explorer and the profile contains the rule `adaptive-rule-read-only-ask *.pdf`. Maybe users will stop using integrated open dialogs and always open files via file explorers. - Example: `firejail qpdf --linearize in.pdf out.pdf` is started in a terminal. - Add configuration directives to automatically grant access to associated files, after the user has granted access to some file. Something like `adaptive-rule-read-write-extra ${FILENAME}.lock` or `adaptive-rule-read-only-extra ${DIRNAME}/*.jpg` (e.g. an image file is opened by an image viewer and the user wants to browse all images in the same folder). - The profile authors should carefully balance between automatically granting access rights to some kind of files and explicitly asking the user. - Example: It might be okay for a PDF viewer to read all PDF files, but the user should be asked if it tries to write to them - Example: A web browser can always write to files in _~/Downloads_, but other files are denied without explicit permission by the user. A configuration file could look like this: ``` adaptive-home adaptive /media # Example for LibreOffice adaptive-rule-read-only-ask *.jpg *.jpeg *.png *.svg # Files that can be included into documents adaptive-rule-read-write-ask *.odt *.ods *.pdf adaptive-rule-read-write-extra ${FILENAME}.lock # Example for PDF viewer, which can read all PDF files without asking the user adaptive-rule-read-only *.pdf adaptive-rule-read-write-ask *.pdf # Example for MonoDevelop adaptive-rule-read-write-ask *.sln # Main file of a project adaptive-rule-read-write-extra ${DIRNAME}/** # Automatically allow access to the whole project ``` What do you think of this idea? Have I overlooked some problem? Was it already proposed?

gitea-mirror

2026-05-05 05:52:52 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 05:52:59 -06:00

Author

Owner

@trou commented on GitHub (Jul 23, 2016):

For information, if you're interested you might want to look into https://github.com/stemjail/stemjail :
StemJail brings to the enduser a mechanism to automatically isolate processes according to the data access pattern (usage).

@trou commented on GitHub (Jul 23, 2016): For information, if you're interested you might want to look into https://github.com/stemjail/stemjail : StemJail brings to the enduser a mechanism to automatically isolate processes according to the data access pattern (usage).

gitea-mirror commented

2026-05-05 05:53:03 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jul 24, 2016):

This is way over my head so it's entirely possible I'm missing something. You clearly know what you're talking about while I can only pick up on little bits here and there :)
My concern is if a jail that is "adaptive" could also be manipulated, and then escaped?

@Fred-Barclay commented on GitHub (Jul 24, 2016): This is way over my head so it's entirely possible I'm missing something. You clearly know what you're talking about while I can only pick up on little bits here and there :) My concern is if a jail that is "adaptive" could also be manipulated, and then escaped?

gitea-mirror commented

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

Author

Owner

@xahare commented on GitHub (Aug 13, 2016):

you can keep separate folders for your apps, just use --private=~/firejails/evince ive been doing this for awhile, and you get used to it quickly. for example, to see a pdf, move it to your evince home folder and view it from there. another bonus is separate contexts, like personal-browser, work-browser, etc

this is easy to wrap from a script, but not quite seamless. you cant just tell the browser to move the file and call your wrapper. but, you can download the file, and call your wrapper from outside firejail to spawn a new one.

@xahare commented on GitHub (Aug 13, 2016): you can keep separate folders for your apps, just use --private=~/firejails/evince ive been doing this for awhile, and you get used to it quickly. for example, to see a pdf, move it to your evince home folder and view it from there. another bonus is separate contexts, like personal-browser, work-browser, etc this is easy to wrap from a script, but not quite seamless. you cant just tell the browser to move the file and call your wrapper. but, you can download the file, and call your wrapper from outside firejail to spawn a new one.

gitea-mirror commented

2026-05-05 05:53:08 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 14, 2016):

@xahare Personally, I like to dedicate one folder (like ~/Downloads) to sharing files between applications. I also find it nicer to use whitelist/blacklist since I have to either hardlink config files that are shared or use bind mounts for whole directories. Either way, that's super messy 😛 Just my personal tastes!

@chiraag-nataraj commented on GitHub (Aug 14, 2016): @xahare Personally, I like to dedicate one folder (like ~/Downloads) to sharing files between applications. I also find it nicer to use whitelist/blacklist since I have to either hardlink config files that are shared or use bind mounts for whole directories. Either way, that's super messy :stuck_out_tongue: Just my personal tastes!

gitea-mirror commented

2026-05-05 05:53:10 -06:00

Author

Owner

@xahare commented on GitHub (Aug 15, 2016):

@Fred-Barclay the dynamic mechanism, or its user, could be tricked. thats always a problem with moving parts.

dynamic / interactive file access would be a good compliment to the access control of firejail and xpra(until we get wayland). dialog boxes should show the full path to files, other hard links, and, if its not a performance hit, sym links.

is there a mechanism with less attack surface than a fuse module?

@xahare commented on GitHub (Aug 15, 2016): @Fred-Barclay the dynamic mechanism, or its user, could be tricked. thats always a problem with moving parts. dynamic / interactive file access would be a good compliment to the access control of firejail and xpra(until we get wayland). dialog boxes should show the full path to files, other hard links, and, if its not a performance hit, sym links. is there a mechanism with less attack surface than a fuse module?

gitea-mirror commented

2026-05-05 05:53:11 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 22, 2018):

Thinking about this again, it seems like a recipe for disaster. As soon as the jail can be modified from within (which is what you're asking for), it is only a matter of time before exploits crop up which attack that adaptability. And as soon as that happens, firejail would be pretty useless.

The thing that makes firejail so powerful is exactly the fact that the jail cannot be modified once it is entered. Adaptability sounds like a good idea at first, but allowing the user to modify the jail from within would (I think) lead to an eventual compromise of the entire jail.

@chiraag-nataraj commented on GitHub (Jul 22, 2018): Thinking about this again, it seems like a recipe for disaster. As soon as the jail can be modified from within (which is what you're asking for), it is only a matter of time before exploits crop up which attack that adaptability. And as soon as that happens, firejail would be pretty useless. The thing that makes firejail so powerful is exactly the fact that the jail cannot be modified once it is entered. Adaptability sounds like a good idea at first, but allowing the user to modify the jail from within would (I think) lead to an eventual compromise of the entire jail.

gitea-mirror commented

2026-05-05 05:53:13 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Aug 6, 2018):

@Unrud, I'm going to go ahead and close this for now. If you have a way to address the concerns that have been brought up here, feel free to respond and re-open :)

@chiraag-nataraj commented on GitHub (Aug 6, 2018): @Unrud, I'm going to go ahead and close this for now. If you have a way to address the concerns that have been brought up here, feel free to respond and re-open :)

Rows
Columns

[GH-ISSUE #641] Idea: Adaptive file access rights #445