I’m looking to run Epiphany in a sandbox so as to block browser access to my users’ folders (and others, why not).
Typically, I don’t want my browser to be able to access my files in my Documents, Videos, Images, Desktop, etc. folders. And let it access only the Download folder (via a bind for example).
I’m already doing this with Firefox and firejail, and it’s working fine.
I think there must be a way of doing this with Epiphany, but I’ve seen that it can’t be launched with Firejail (or any other similar solution) because the process is already containerized with bwrap.
So my question is: how can I control access to my file system/block access to user folders so that Gnome-Web launches without seeing my personal folders?
I guess you’d have to use commands like bwrap and unshare directly… But I can’t find a working solution.
Just use flatseal? That would be the easiest way. You’d need to block access to at least the document portal and the file chooser portal. Alternatively, maybe you can configure Firejail to not disallow user namespaces; that’s my guess as to what most likely breaks bwrap.
Ideally there would be a kiosk mode that would disable file choosers automatically without need for an extra sandboxing layer, but that doesn’t exist currently.
My plan is to remake this project and adapt it to Epiphany, which is lighter.
Basically: to be able to launch several totally separate Epiphany instances in parallel (already possible with the -p option). But to be able to offer 2 types of instances: one with access to the Downloads folder, and one without any access.
I’ve tried to get Epiphany to work in firejail, but it’s impossible. I can’t find an option allowing namespace creation within firejail…
If you just want to block file choosers, it might be easier to do this as a setting rather than a sandboxing layer:
Add a hidden gsetting block-file-choosers
If setting is enabled, immediately call webkit_file_chooser_request_cancel() in ephy_web_view_run_file_chooser
This should be a relatively easy first project for someone who knows at least one programming language but hasn’t worked on Epiphany before. But that won’t stop users from manually opening files using file URLs. If you’re concerned about that, it would need to be yet another setting, and it would be harder to implement because it would need to be done in WebKit.
Hm, I’m not sure why flatseal isn’t flexible enough for you? That seems like the easiest option.
It’s all my user files that I want to block, and not just appearances. The idea is to assume that there’s a client-side attacker looking to retrieve some of my files, and I want to prevent him from doing so.
So there has to be a real block on access to my files. I don’t really see the point of just preventing the file selector from being displayed…
For flatseal, the problem is that I wouldn’t be able to simultaneously open an Epiphany instance that has access to my Downloads folder that I authorize it to access (or anything else for that matter), and an instance that doesn’t have access to anything.
On the other hand, in sandbox mode (I’m already doing this with Firefox and Firejail, as shown by the link in my previous post), I’ve set up options that allow me to start up in either permissive (access to the download folder only) or non-permissive (access to nothing except the bare essentials) mode.
I’d like to be able to do the same thing with Epiphany, because it would be much more efficient than with Firefox.
You can configure permissions with flatpak run too. Flatseal just sets your defaults. I think you just need two desktop files that launch the app with different permissions. Both should block access to at least the file chooser portal and the documents portal using --no-talk-name. One would block access to ~/Downloads (--nofilesystem=xdg-download) and the other would not.
Maybe you want to block all portals and allow only the ones you specifically want. That’s fine too. You can even block the entire session bus and allowlist only specific names. It’s pretty flexible.
I didn’t know you could specify folder access or blocking in the flatpak run command parameters.
I’ve just tried… and it doesn’t work with Epiphany. I run flatpak run --nofilesystem=**** or flatpak run --filesystem=****, (**** designates for example: xdg-download or my path to my user’s Downloads folder) and Epiphany still has access to everything as if the option were not used.
Yes, I understand that.
But I don’t see how I can tell the flatpak APIs to tell an app at startup whether it should have access to my user folders or not.
With Firefox, my solution is simple: I start firejail in a folder that I define and that contains the firefox profile, and depending on the icon that has been clicked, I mount my Downloads folder to make it accessible (with the bind command). In this way, I ensure that firefox has no unwanted access to my user folders (in addition to deleting all traces of firefox when I close it).
OK, I misunderstood. I thought you were trying to create a kiosk mode where users would not be able to open files from the host filesystem.
That said, I have no clue how Epiphany is able to access your host filesystem. That should be impossible; unless allowed by your custom permissions, that would indicate a major newsworthy security bug in flatpak, so I’m skeptical. Please provide more information demonstrating precisely how you’ve determined it has filesystem access. (Obviously your steps should not involve any file choosers, since you are allowing that portal.)
Here’s my configuration in flatseal for filesystem access…
I open the browser with flatpak (I’ve uninstalled the apt version). I press Ctrl+O, and here I am with the ability to access any of my user’s folders (here Images):
I also have access to everything with the following commands:
flatpak run --nofilesystem=/home/user/Téléchargements org.gnome.Epiphany
flatpak run --filesystem=/home/user/Téléchargements:ro org.gnome.Epiphany
flatpak run --filesystem=xdg-download:ro org.gnome.Epiphany
flatpak run --no-talk-name --nofilesystem=xdg-download org.gnome.Epiphany etc…
Knowing that I’m running debian 12, up to date (stable version + backports).
For avoidance of doubt: you cannot use the file chooser to decide what the browser has permission to access, because you’ve decided not to block the portal, so the file chooser is running on the host system. The browser only gets to see the file that the user chooses to open, mounted by the document portal somewhere under /run.
You can use file URLs like file:/// or file:///home to actually review the browser’s view of the filesystem.
But what’s the point?
Whether there’s a file selection tool or not, it’s the sandbox that must block and render invisible the very existence of folders.
Whether the file selection tool is visible or not, a malicious program will have access to my folders/files. And I don’t want that.
And when I try to open a file with marktext, I only have access to my user’s Downloads folder, as well as the /tmp folder (I have to enter the folder path by hand, then it displays the contents without any problem). But if I enter /home/user/Pictures by hand, nothing happens: I can’t see the contents of this folder, even though it exists.
This is a bit unintuitive, but the file chooser is outside the sandbox, so the app can only request to open the dialog; it cannot see or interact with it. Only the file that you select gets shared with the app via the document portal. In other words, this is a feature, not a bug.
This app apparently doesn’t support the file chooser portal, so you’re getting a traditional in-process file chooser inside the sandbox. I’d guess that it’s using too old a version of Electron.
But in that case, what’s the point of the sandbox when it comes to accessing files, since they can be accessed even when access is blocked?
Because even if I hide the selector, I can still access it by entering the file path manually!
A sandbox that lets everything through is useless…
In my case, where, from a security point of view, I want to block access to all user files (except download files), this is not possible with flatpak.
If I block access to everything in flatseal (or with command-line arguments), I can still open my files by entering the file path manually.
So what’s the use of flatpak?
What’s more, I remembered that the file selector was offered by flatpak to the app, and not used by the system.
To repeat what Chris already said: the application has no access to the file chooser. It cannot see any of those files. It cannot see the file chooser window (assuming you’re using Wayland and not X11). Even after you select the file, the application still doesn’t learn where it exists on your host filesystem. It’s designed such that only the user and not the application can see the host files.
If sandboxing applications required that users not be able to select files, users wouldn’t use sandboxed applications and the whole exercise would have been pointless. So: file chooser portal.
I’ve lost track of how many times I’ve suggested that you block the file chooser portal. At this point, I’m not sure what else to say. Try it and report back, or not.
