[Feature request]: A filesystem access permission for the user's home folder excluding dotfiles

[PlasmaPower]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

There's been some adjacent discussion to this in #3637 and #4151, but I haven't seen a specific issue for granting access to the user's home folder excluding all files and folders starting with a .. These are usually internal to specific applications on Linux, and importantly the most universal and straightforward methods of sandbox escape are via these files, such as .bashrc, .bash_profile, and .config/autostart.

This wouldn't be suitable for all applications currently using the home permission, but it could help improve the security of applications which need access to a user's files but not system internals, such as media players and editors.

This isn't intended to prevent all conceivable methods of sandbox escape -- one might imagine a program automatically inserting malware into any executable files it finds in the Downloads folder for instance -- but it prevents the sandbox escapes which are the most universal and don't require user action to run the malware outside the sandbox.

[Erick555]

I wish it could work like that but it's not possible.

[PlasmaPower]

I'm not familiar with flatpak internals. Is that due to how the directory is bound into the container? Would it be possible to e.g. use a fuse mount for this, or in the worst case individually bind non-dotfile directories and files in the home folder?

For the latter, I could imagine syntax like allowing the filesystem path ~/*, which under bash globbing rules would exclude dotfiles.

[Erick555]

I think this is problem with iterating over all directories and filter them. Flatpak doesn't use bash or any shell. Also flatpak is focused on accessing files through portal and direct file access is a workaround if the former isn't feasible.

[PlasmaPower]

I'm aware that this isn't ideal, but it could significantly improve the security of several popular apps on flatpak. My two ideas to implement this are:

• Create a FUSE mount that hides dotfiles. This is probably the ideal solution, but it might be complex to implement.
• Iterate over all non-hidden directories and files in the root of the home folder when binding, and bind them individually. This doesn't hide dotfiles not in the root of the home folder, and doesn't bind newly created files/folders in the root of the home folder, but it is easy to implement. My point with the syntax was not that it'd be implemented with bash but that it would help users understand this functionality, as it's what bash would do with the same syntax.

[boredsquirrel]

how is the block of home/.var/app done?

Flatsweep has that directory as permission and can access it, all other apps cannot.

If this works for that dir, why not for all?

This would be very needed, if not for all dotfiles, then simply for a set of blocked directories and files?

home/.bashrc
home/.bash_profile
home/.bash_history
home/.bash_logout
home/.zshrc
home/.config
home/.ssh
home/.gnupg
home/.mozilla
home/.thunderbird
home/.librewolf
home/.local
home/.cache
# home/.local/share/flatpak/overrides

also see the hardcoded paths of software

[Erick555]

You can block specific dot dir but not all. Hardcoded blocklist may give false sense of security since depending on system it may miss a lot of sensitive paths.

[boredsquirrel]

@Erick555 this is purely a harm reduction method. If there is no clean way to block .* this is needed.

Of course portals are the best way, but having used some apps with only portals, I dont know if they really work that well. Imagine a gallery app, opening one image and then wanting to show others.

[rusty-snake]

how is the block of home/.var/app done?

Mount a tmpfs over it (bwrap: --tmpfs $HOME/.var/app).

This also means you can only block files that exist. So either you create all sensitive files (some users are picky about their dotfiles) or the program can just create them.

[Erick555]

@Erick555 this is purely a harm reduction method. If there is no clean way to block .* this is needed.

This isn't needed if you use allowlist of specific paths under home which is easy to do right now and al security conscious users do it. Fans of blocklist security theater can easily find other projects that rely on it.

[PlasmaPower]

I use an allowlist for all my apps as well, but this is about marginally improving defaults for users who don't manually configure permissions. Many apps on flatpak by default get full home folder access, and limiting that to exclude dotfiles by default would be a small step in the direction of more secure systems.

[boredsquirrel]

@Erick555 I want to stress that I agree on your point to not build in hacky workarounds.

But Flatpak is the easy way to install GUI apps. And the Linux Desktop does not have the marketshare to dictate that every app needs to use portals.

The other way around, it is very easy to just upload an app with broad permissions and call it a day, the security rating is just a recommendation.

I have not found a good solution for automatically changing the permissions of apps with home permission, to something more specific. This takes manual work, which people are not expected to invest on many distros.

Example: Fedora will not preinstall Flatseal, which afaik prevents users from hardening their permissions. On KDE this is possible, but still not easy.

Especially as we know 90% of critical directories, having such a fix would be netto positive.

[Mikenux]

I think it depends on how a solution that doesn't give dot files affects app startup (also important for users). Note that I don't mean that a solution can't be developed if this is the case, but it must be a different permission (as suggested) than the "home" one. Also, if this new permission affects app startup, I wouldn't expect app developers to use it by default.

Of course portals are the best way, but having used some apps with only portals, I dont know if they really work that well. Imagine a gallery app, opening one image and then wanting to show others.

It is flatpak/xdg-desktop-portal#463, but I don't know which solution is being worked on.

[colleirose]

I would suggest there should be 5 permissions levels for what access to the home directory an app can request:

1. Full read and write access to the home directory
2. Full read access to the home directory without any write access
3. Full read and write access for most of the home directory, but without write or read access to the files starting with a dot
4. Full read and write access for most of the home directory with only read access to the files starting with a dot
5. No home access at all

I do not know how this could be implemented because I also am not familiar with Flatpak's internals, but in my opinion this is a security-critical feature. The ability for most Flatpak apps to read and write anything in the home directory enables very trivial sandbox escapes. Flatpak is often promoted for its security and yet this is a trivial and easily exploitable security issue.

If this is actually something possible to fix then I am more than willing to look into fixing it. Flatpak is very promising for making Linux more secure, so implementing this is crucial. Flatpak has had a major security vulnerability for years and yet little to nothing has been done to fix it. That isn't acceptable. Some apps require access to everything in home, but most do not. Like VS Code: most people are not using it to update their bashrc or ssh or whatever files, and if they were, they should be able to explicitly prompted before giving such acccess, similar to #5304 which was closed because it (in the words of the person who closed it) "technically" already exists in an extension of Flatpak (if you use Flatpak from the command line because you don't want to install yet another app, the feature doesn't exist).

It appears that another issue requesting this (#3637) got closed as resolved (it was not resolved), maybe this one will get closed too. It's rather frustrating how little attention is being paid to very important security features. Flatpak does not provide proper sandboxing when file system access is like this.

[Mikenux]

Static permissions are globally not recommended because they are sandbox holes. Also note that having multiple home access permissions will not force apps to use the relevant one for their specific case. And even if home access is improved, there are other static permissions that are problematic.

Apps not needing this permission and for the best file restriction, they are expected to use portals, and this will not change. There is flatpak/xdg-desktop-portal#1269 which is made for apps needing this to move away from home as apps are using it for this feature. If apps are using home access for another feature or if there are other problems, then this is something to improve in portals.

[colleirose]

Static permissions are globally not recommended because they are sandbox holes

And having read and write access to every file in the home directory isn't a sandbox hole?

Also note that having multiple home access permissions will not force apps to use the relevant one for their specific case

Yes, but it will make it more likely, currently there is no way for an app to have tailored access even if it wants to.

And even if home access is improved, there are other static permissions that are problematic.

Okay, and why does this mean home access shouldn't be improved?

Apps not needing this permission and for the best file restriction, they are expected to use portals, and this will not change. There is flatpak/xdg-desktop-portal#1269 which is made for apps needing this to move away from home as apps are using it for this feature. If apps are using home access for another feature or if there are other problems, then this is something to improve in portals.

Why won't it change? A third-party app being able to fix the problems with Flatpak's sandbox does not justify having a broken sandbox. Also, the PR you linked has nothing to do with obtaining limited access to the home folder.

As far as I can tell, it is not possible for an app to choose to have access to only specific home files or folders, or to restrict access to files that are usually executable. "This will not change" is not an explanation for why it shouldn't change.

[Mikenux]

And having read and write access to every file in the home directory isn't a sandbox hole?

You can already have home read-only. See https://docs.flatpak.org/en/latest/sandbox-permissions.html#filesystem-access.

And even if home access is improved, there are other static permissions that are problematic.

Okay, and why does this mean home access shouldn't be improved?

You can definitely improve it (I didn't mean you can't). Just make sure your solution doesn't slow down app startup so much that this new option won't be used.

Why won't it change? A third-party app being able to fix the problems with Flatpak's sandbox does not justify having a broken sandbox. Also, the PR you linked has nothing to do with obtaining limited access to the home folder.

As far as I can tell, it is not possible for an app to choose to have access to only specific home files or folders, or to restrict access to files that are usually executable. "This will not change" is not an explanation for why it shouldn't change.

A really sandboxed app has no access to host files at all (https://docs.flatpak.org/en/latest/sandbox-permissions.html), even if read-only (an app, depending on its other permissions, can share files for example).

The PR I linked is an example of a feature which explain why some applications are still using home access rather than the file chooser portal (which allow the user to limit access to selected files or directories, thus limiting sandbox holes).

What will not change is that apps should use portals rather than static permissions.