[GH-ISSUE #2644] Allow ~/VirtualBox VMs/shared for all the apps

gitea-mirror commented

2026-05-05 08:19:01 -06:00

Owner

Originally created by @KOLANICH on GitHub (Apr 12, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2644

I guess it makes sense to dedicate ~/VirtualBox VMs/shared to exchange data between apps and VMs. And disallow ${Downloads}.

Originally created by @KOLANICH on GitHub (Apr 12, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2644 I guess it makes sense to dedicate `~/VirtualBox VMs/shared` to exchange data between apps and VMs. And disallow `${Downloads}`.

gitea-mirror closed this issue

2026-05-05 08:19:02 -06:00

gitea-mirror commented

2026-05-05 08:19:04 -06:00

Author

Owner

@Vincent43 commented on GitHub (Apr 12, 2019):

Definitely we don't want all apps to exchange data with VMs as default. You may add local override for that if you wish.

@Vincent43 commented on GitHub (Apr 12, 2019): Definitely we don't want all apps to exchange data with VMs as default. You may add local override for that if you wish.

gitea-mirror commented

2026-05-05 08:19:05 -06:00

Author

Owner

@KOLANICH commented on GitHub (Apr 12, 2019):

Definitely we don't want all apps to exchange data with VMs as default. You may add local override for that if you wish.

It is optin. It is not meant to store vdi files and vm settings in this folder. What is meant is moving iso images into this folder in order to give virtualbox access to them and creating shared fllders in this dir

@KOLANICH commented on GitHub (Apr 12, 2019): >Definitely we don't want all apps to exchange data with VMs as default. You may add local override for that if you wish. It is optin. It is not meant to store vdi files and vm settings in this folder. What is meant is moving iso images into this folder in order to give virtualbox access to them and creating shared fllders in this dir

gitea-mirror commented

2026-05-05 08:19:06 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Apr 26, 2019):

If you want to use a shared folder, you probably should use ${DOWNLOADS} for that purpose. That's kinda the point of a Downloads folder - to share data between different programs that shouldn't see each others' data otherwise (when I used to use VirtualBox, I used ${DOWNLOADS} for exactly this purpose).

If you want to use VirtualBox VMs/shared for that purpose locally, by all means go ahead! But I don't think it's appropriate to have that as the default.

@chiraag-nataraj commented on GitHub (Apr 26, 2019): If you want to use a shared folder, you probably should use `${DOWNLOADS}` for that purpose. That's kinda the point of a Downloads folder - to share data between different programs that shouldn't see each others' data otherwise (when I used to use VirtualBox, I used `${DOWNLOADS}` for _exactly_ this purpose). If you want to use `VirtualBox VMs/shared` for that purpose locally, by all means go ahead! But I don't think it's appropriate to have that as the default.

gitea-mirror commented

2026-05-05 08:19:07 -06:00

Author

Owner

@KOLANICH commented on GitHub (Apr 26, 2019):

If you want to use a shared folder, you probably should use ${DOWNLOADS} for that purpose.

I definitely shouldn't - Downloads is shared with a browser.

That's kinda the point of a Downloads folder - to share data between different programs that shouldn't see each others' data otherwise (when I used to use VirtualBox, I used ${DOWNLOADS} for exactly this purpose).

No, it's not. Its purpose is to store downloaded files.

The fj UX is terrible. We need a better one.

For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits), having access to whole ~. I mean replacing the functions opening them with the ones asking firejail to open them. And they are executed in a separate processes isolated from both the app and firejail and the only permissions they have are to view the whole home. Then when a user selects a file, grant the sandboxed app access to that file only.

@KOLANICH commented on GitHub (Apr 26, 2019): >If you want to use a shared folder, you probably should use ${DOWNLOADS} for that purpose. I definitely shouldn't - Downloads is shared with a browser. >That's kinda the point of a Downloads folder - to share data between different programs that shouldn't see each others' data otherwise (when I used to use VirtualBox, I used ${DOWNLOADS} for exactly this purpose). No, it's not. Its purpose is to store downloaded files. The fj UX is terrible. We need a better one. For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits), having access to whole `~`. I mean replacing the functions opening them with the ones asking firejail to open them. And they are executed in a separate processes isolated from both the app and firejail and the only permissions they have are to view the whole home. Then when a user selects a file, grant the sandboxed app access to that file only.

gitea-mirror commented

2026-05-05 08:19:07 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Apr 26, 2019):

I definitely shouldn't - Downloads is shared with a browser.

I presume you're downloading these files? Like, it's good practice to reserve one directory solely for sharing files between programs. For most people, that will be the ${DOWNLOADS} directory. This includes the browser, office software, virtual machine managers, etc. If you don't want all programs to access it, it shouldn't be in ${DOWNLOADS}.

Also, as @Vincent43 said, we want to isolate virtual machines completely by default (with the exception of the dedicated sharing folder). So no, random programs shouldn't have access to ~/Virtualbox VMs/shared.

I also don't quite understand your threat model here. Any directory you're sharing between programs (whether ${DOWNLOADS} or some other directory) is liable to be abused to transmit malicious stuff. That's an inherent risk you are taking simply by not completely isolating every program from every other program (if there are shared folders, the programs aren't completely isolated).

For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits), having access to whole ~. I mean replacing the functions opening them with the ones asking firejail to open them. And they are executed in a separate processes isolated from both the app and firejail and the only permissions they have are to view the whole home. Then when a user selects a file, grant the sandboxed app access to that file only.

This is way, waaaaaay beyond the scope of firejail. It would require completely redesigning the way most toolkits and programs behave. I agree it would be an awesome idea, but it's certainly not happening here and doesn't really reflect poorly on firejail that it's not trying to hook into programs in places where they're not designed to be hooked into.

@chiraag-nataraj commented on GitHub (Apr 26, 2019): > I definitely shouldn't - Downloads is shared with a browser. I presume you're downloading these files? Like, it's good practice to reserve one directory solely for sharing files between programs. For most people, that will be the `${DOWNLOADS}` directory. This includes the browser, office software, virtual machine managers, etc. If you don't want all programs to access it, it shouldn't be in `${DOWNLOADS}`. Also, as @Vincent43 said, we want to _isolate_ virtual machines completely by default (with the exception of the dedicated sharing folder). So no, random programs shouldn't have access to `~/Virtualbox VMs/shared`. I also don't quite understand your threat model here. Any directory you're sharing between programs (whether `${DOWNLOADS}` or some other directory) is liable to be abused to transmit malicious stuff. That's an inherent risk you are taking simply by not _completely_ isolating every program from every other program (if there are shared folders, the programs aren't completely isolated). > For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits), having access to whole ~. I mean replacing the functions opening them with the ones asking firejail to open them. And they are executed in a separate processes isolated from both the app and firejail and the only permissions they have are to view the whole home. Then when a user selects a file, grant the sandboxed app access to that file only. This is _way_, **_waaaaaay_** beyond the scope of `firejail`. It would require completely redesigning the way most toolkits and programs behave. I agree it would be an awesome idea, but it's certainly not happening here and doesn't really reflect poorly on firejail that it's not trying to hook into programs in places where they're not designed to be hooked into.

gitea-mirror commented

2026-05-05 08:19:08 -06:00

Author

Owner

@KOLANICH commented on GitHub (Apr 26, 2019):

Any directory you're sharing between programs (whether ${DOWNLOADS} or some other directory) is liable to be abused to transmit malicious stuff.

Exchanging malicious stuff by 2 malwares in different sandboxes is not in threat model. Malicious stuff is safe unless it is processed. It safe to assumme that any malicious stuff in the system is processed by a vulnerable thumhnailer and a search indexer if they are enabled. As long as you have them disabled, you are safe in the sense that b dropping that file is not enough to bypass sandboxing.

The concern on Download folder is that it is a very dangerous folder to allow it be accessed by every program:

they can spy on your downloads
they can maliciously modify downloads

That's an inherent risk you are taking simply by not completely isolating every program from every other program (if there are shared folders, the programs aren't completely isolated).

That's why we need dedicated shared folders for almost each app, only privileged apps like dolphin or mc are allowed to access them all.

@KOLANICH commented on GitHub (Apr 26, 2019): >Any directory you're sharing between programs (whether ${DOWNLOADS} or some other directory) is liable to be abused to transmit malicious stuff. Exchanging malicious stuff by 2 malwares in different sandboxes is not in threat model. Malicious stuff is safe unless it is processed. It safe to assumme that any malicious stuff in the system is processed by a vulnerable thumhnailer and a search indexer if they are enabled. As long as you have them disabled, you are safe in the sense that b dropping that file is not enough to bypass sandboxing. The concern on Download folder is that it is a very dangerous folder to allow it be accessed by every program: * they can spy on your downloads * they can maliciously modify downloads >That's an inherent risk you are taking simply by not completely isolating every program from every other program (if there are shared folders, the programs aren't completely isolated). That's why we need dedicated shared folders for almost each app, only privileged apps like dolphin or mc are allowed to access them all.

gitea-mirror commented

2026-05-05 08:19:09 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Apr 26, 2019):

The concern on Download folder is that it is a very dangerous folder to allow it be accessed by every program:

Not inherently any more dangerous than allowing any other directory to be shared with all programs...it's just a directory. Any directory that is shared between multiple programs, at least one of which has internet access will have the problems you mention.

That's why we need dedicated shared folders for almost each app, only privileged apps like dolphin or mc are allowed to access them all.

Cool. If you can figure out a way to make this work seamlessly without breaking everyone's programs, go for it and submit a pull request. I personally don't think that model will work seamlessly for most users (it will work well for those of us who are used to firejail and working around issues we find).

Or, develop your own set of profiles (like I did), create a repo, and we'll add it to our list of repos in the README.

One thing I can guarantee is that we're not going to adopt that model unless it's clear that it's not going to break the normal user's setup. And given that we still haven't even moved fully over to a whitelist system (due to issues with various paths differing between users and distros), I highly doubt we'll adopt this approach. If you feel this strongly about it, please submit pull requests and see how it goes :)

This will be the last time I respond - I don't think we're ever going to agree, and as far as I can tell, the consensus seems to be on this thread that this isn't happening, at least not right now. If other people want to respond, feel free.

@chiraag-nataraj commented on GitHub (Apr 26, 2019): > The concern on Download folder is that it is a very dangerous folder to allow it be accessed by every program: Not inherently any _more_ dangerous than allowing any *other* directory to be shared with all programs...it's just a directory. _Any_ directory that is shared between multiple programs, at least _one_ of which has internet access will have the problems you mention. > That's why we need dedicated shared folders for almost each app, only privileged apps like dolphin or mc are allowed to access them all. Cool. If you can figure out a way to make this work seamlessly without breaking everyone's programs, go for it and submit a pull request. I personally don't think that model will work seamlessly for _most_ users (it *will* work well for those of us who are used to `firejail` and working around issues we find). Or, develop your own set of profiles (like I did), create a repo, and we'll add it to our list of repos in the README. One thing I can _guarantee_ is that we're not going to adopt that model unless it's clear that it's not going to break the normal user's setup. And given that we still haven't even moved fully over to a whitelist system (due to issues with various paths differing between users and distros), I highly doubt we'll adopt this approach. If you feel this strongly about it, please submit pull requests and see how it goes :) This will be the last time I respond - I don't think we're ever going to agree, and as far as I can tell, the consensus seems to be on this thread that this isn't happening, at least not right now. If other people want to respond, feel free.

gitea-mirror commented

2026-05-05 08:19:10 -06:00

Author

Owner

@Vincent43 commented on GitHub (Apr 27, 2019):

For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits),

Flatpak does something like this with dbus portal. This needs support from the app though.

@Vincent43 commented on GitHub (Apr 27, 2019): > For example substitute open dialogs provided by GTK and Qt with trusted own ones (based on the same toolkits), Flatpak does something like this with dbus portal. This needs support from the app though.

gitea-mirror commented

2026-05-05 08:19:10 -06:00

Author

Owner

@KOLANICH commented on GitHub (Apr 27, 2019):

What's wrong with hooking?

@KOLANICH commented on GitHub (Apr 27, 2019): What's wrong with hooking?

gitea-mirror commented

2026-05-05 08:19:11 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 20, 2019):

What's wrong with hooking?

I know I said my last message was my last one on this thread, but I guess I'll respond to this question.

As I said earlier, hooking into toolkits and stuff is way beyond the scope of Firejail. Firejail tries to be minimalistic, simple, and effective. What you are suggesting would greatly increase the code and complexity of firejail and make it a lot more prone to security holes and so on.

Listen, if you want to sit down and develop hooks for this stuff, go right ahead, and once you've done it, feel free to create a pull request and we can have that discussion there. But I personally feel that it would be an awful idea for all the reasons I mentioned.

Regardless, it's clear from the comments here that whitelisting ~/Virtualbox VMs/shared for all programs is not going to happen, and I'll close this issue. @KOLANICH, feel free to re-open if you believe you can convince us to allow that directory by default. As for the hooking issue, feel free to either create a new issue (and make the case for it there) or, if you have an idea of how it would work, feel free to implement it and create a pull request.

@chiraag-nataraj commented on GitHub (May 20, 2019): > What's wrong with hooking? I know I said my last message was my last one on this thread, but I guess I'll respond to this question. As I said earlier, hooking into toolkits and stuff is **way** beyond the scope of Firejail. Firejail tries to be minimalistic, simple, and effective. What you are suggesting would greatly increase the code and complexity of firejail and make it a _lot_ more prone to security holes and so on. Listen, if you want to sit down and develop hooks for this stuff, go right ahead, and once you've done it, feel free to create a pull request and we can have that discussion there. But I personally feel that it would be an awful idea for all the reasons I mentioned. Regardless, it's clear from the comments here that whitelisting ~/Virtualbox VMs/shared for all programs is not going to happen, and I'll close this issue. @KOLANICH, feel free to re-open if you believe you can convince us to allow that directory by default. As for the hooking issue, feel free to either create a new issue (and make the case for it there) or, if you have an idea of how it would work, feel free to implement it and create a pull request.

Rows
Columns

[GH-ISSUE #2644] Allow ~/VirtualBox VMs/shared for all the apps #1670