Flatpak: "home" access allows trivial privilege escalation, what to do instead

Ask Fedora
, , , , , , , , ,
1

This Github issue describes the problem well

If an app has the static filesystem permission for home, it can place this override file to give itself any possible permission.

mkdir ~/.local/share/flatpak/overrides
cat >> ~/.local/share/flatpak/overrides/my.awesome.App <<EOF
[Context]
shared=network;ipc
sockets=x11;wayland;fallback-x11;pulseaudio;session-bus;system-bus;ssh-auth;
pcsc;cups
devices=dri;kvm;shm;all
features=devel;multiarch;bluetooth;canbus
filesystems=host;host-os;host-etc;home
EOF

This concept is actually how Flatseal works, placing override files for each app and thus modifying their permissions.

If this was only possible for reducing the permissions, it would be harmless and even useful. But it is a direct way for privilege escalation instead.

The issue was closed, which I find concerning. The general tone is

If an app has home permission, dont expect it to be secure.

I think this is pretty bad and there are 2 ways to tackle this.

1. Block access to all dotfiles.

Apps that have home permission can no longer read and write

  • your ~/.bashrc
  • your ssh and gpg keys
  • these permission overrides
  • …

and much more. Flatpaks have no business in the dotfiles, even though Cryptomator devs think it should.

And even if apps need that, they can specify the exact directories. This is how Flatsweep does it, while Flatpak normally blocks access to ~/.var/app (to allow “containerization”, while all apps with home permission could just change their permissions, lol)

"--filesystem=home/.var/app/",
"--filesystem=/var/lib/flatpak/app:ro",
"--filesystem=home/.local/share/flatpak/app:ro"

But this needs to be done at a Flatpak level, see this issue.

2. Override for all apps with home permission

I really like @pkmays’ approach to this

They used a general override for all apps, resulting in a permission page like this:

KDE Plasma systemsettings permission page

This works really well, but as a side effect (I think) breaks all preset permissions by apps. There are very few apps like Gnumeric that have too little permissions, but most have just the permissions they need.

So this would sometimes lead to extended privileges and lots of manual work (it is not a scaleable concept).

What would be a good way to do a function, all apps with home permission get such an override file placed? Best would be in a non user-writable directory.

Are there differences in --user and system installed apps?

6 Likes
2

Having a variant of the home permission that excluded hidden files would be nice to have, but only if it could be implemented cleanly, and that doesn’t seem to be the case. Neither of the options mentioned in flatpak/flatpak#4632 (comment) are really viable. Moreover, even if sandbox escape would be more difficult without dotfile access, it’s still fundamentally insecure. Consider a ransomware attack encrypting all your files for example.

As a user, you could play whac-a-mole with all the directories you can think of, but I’m not sure it’s worth the pain given the limited benefit.

Improving portals and portal adoption is the only real way out. Until then, I’m pretty cautious about running apps with home (or greater) access and will take it away if it’s not really necessary (e.g. Evince).

3 Likes
3

i discover today that gnome-boxes dont respect the flatseal when i turn off internet on it, it still continuous to access internet.

I though these permissions on flatseal would enforce the flatpak, but i discover that is not true

1 Like
4

That does seem to work, but Boxes likes to run in the background, so you need to terminate it or restart your session after removing the permission. See flatpak ps and flatpak kill.

2 Likes
5

Insteresting, i didnt allow in gnome settings the permission to it run in background and even denied it didnt respect, gonna try this command, thanks

6

you were right , i open it, close it and it still shows, running flatpak ps, but it dont show in gnome system “running in background”. I have other flatpaks that shows in “gnome background apps” after closing it but not boxes

1 Like
7

Yes that is true.

But as mentioned, “we just need to implement portals everywhere” is not an argument to lay back and do nothing for like 5 years until that is done.

I maintain a list of modern flatpak apps.

This and the security rating on Flathub and GNOME Software (not yet in KDE, COSMIC and not sure about other DEs) are the only way to have some kind of security.

And still, there seems to be a way for ~/.var/app so I dont think it is impossible?

The other way around, “sandboxed” flatpak apps give a false sense of security.

2 Likes
9

That doesn’t work because you (or a malicious app) can delete a root-owned file in a directory you own and recreate it.

3 Likes
11

Added howto

12

I just stopped caring about the sandbox that flatpak provides when I realized that there are just too many security holes to exploit.

For example, if an application is granted with --talk-name=org.freedesktop.FileManager1 and you have Nautilus installed, the application can simply call the dbus method of Nautilus (org.gnome.Nautilus.FileOperations.CopyURIs) to copy the files between the host and the sandbox (e.g. ~/.bashrc and ~/.var/app/<appid>/.bashrc). It can easily achieve sandbox escape by writing dotfiles.

At first, it appeared to me that granting --talk-name=org.freedesktop.FileManager1 was safe, because file-manager-interface only shows three harmless methods: ShowFolders/ShowItems/ShowItemProperties. But the implementation of Nautilus provides more methods (I guess other file managers provide them too).

The problem is that, as a user, you never know whether granting a permssion is safe.

1 Like
13

Flathub enforces strict permissions (at least now, as they became bigger).

Good example:

(But there are people trying to still fix this: Add binary on flathub ¡ rustdesk/rustdesk ¡ Discussion #1537 ¡ GitHub)

Also, users should not grant permissions manually, at most restrict them. Granting is done in the PR phase where knowledgeable people look at it.

14

@boredsquirrel That’s a modest discussion. I’ve seen and lived through some worse ones.

15

I didnt mean to grant more permissions manually. I just want to make sure the permissions granted to the applications are safe as they seem to be. But as a normal user, you don’t know what the implication of a requested permission is. You have to manually check all dbus methods in the permission list are safe because something like Naulitus may provide some unsafe methods.

While I appreciate flathub’s effort to enforce strict permissions, I don’t think it is the solution. Applications would have legitimate reasons to request something like --talk-name=org.freedesktop.FileManager1. If they block such applications, then many useful applications would be unavailable from flathub.

And --talk-name=org.freedesktop.FileManager1 is just an example, I don’t know what the next is.

1 Like
16

Don’t worry, I the future Flapak manifest will not have any arguments, everything will go through Portals. In the future

1 Like
17

Eh. But in the present days, every program you install from the repository, from third party ones, directly from RPM, or that you compile from source, or that you install with pip, cargo, or curl (!), they have full access to your system. I don’t want to start an endless discussion, but let me say that it is not clear to me why there is such a big concern with flatpaks.

2 Likes
18

you can report this to flathub people. An app may need to be restricted afterwards.

This exact case should be prevented in advance.

The implementation of the various desktops is of course relevant here

19

So you don’t run your software from Containers? :thinking: j/k :+1:t5: