[Bug]: Can't access /usr with permission

[JakobDev]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.15.4

What Linux distribution are you using?

Manjaro Linux

Linux distribution version

latest

What architecture are you using?

x86_64

How to reproduce

Give a Flatpak the filesystem=host:ro permission. now you can access the /usr directory f the Host as /run/host/usr inside the Flatpak.

Now remove the filesystem=host:ro permission and add the filesystem=/usr/share/applications:ro instead.

Expected Behavior

You should be able to access /usr/share/applications from the host inside the Flatpak as /run/host/usr/share/applications.

Actual Behavior

When starting the Flatpak you get an F: Not sharing "/usr/share/applications" with sandbox: Path "/usr" is reserved by Flatpak error and can't access the directory.

Additional Information

No response

[rusty-snake]

You should be able to access /usr/share/applications from the host inside the Flatpak as /run/host/usr/share/applications.

Maybe --filesystem=host-os/share/applications or so would make this more explicit.

[JakobDev]

Maybe --filesystem=host-os/share/applications or so would make this more explicit.

Unbfortunally not.

Unknown filesystem location host-os/share/applications, valid locations are: host, host-os, host-etc, home, xdg-*[/…], ~/dir, /dir

[smcv]

This is not possible. As the error message says, /usr is "owned" by Flatpak (for the runtime) and you cannot add it as a permission: that's why we have host-os, to give you a different route to access the host's /usr.

[smcv]

host-os does not support sharing subsets of /usr: as a simplification, it's all-or-nothing. All of /usr is controlled by the OS vendor and/or sysadmin, via OS-level package managers or similar, so it doesn't seem like there's any security advantage to having access to some but not all of it?

[qoijjj]

host-os does not support sharing subsets of /usr: as a simplification, it's all-or-nothing. All of /usr is controlled by the OS vendor and/or sysadmin, via OS-level package managers or similar, so it doesn't seem like there's any security advantage to having access to some but not all of it?

The security advantage would be the Principle of Least Privilege. In other words, why punch a bigger hole in the sandbox than is necessary?

For example, in my project we are looking at various methods of getting flatpaks to work with hardened_malloc. We have them running with hardened_malloc, using the steps documented here: secureblue/secureblue#67 (comment)

In short, we can directly reference

 --env=LD_PRELOAD=/var/run/host/usr/lib64/libhardened_malloc.so

The only downside is that this requires

--filesystem=host-os:ro

Which gives all flatpaks readonly access to all of /usr.

It would be good if instead, we could do:

--filesystem=host-os/lib64/libhardened_malloc.so:ro

Or something to that effect. Something more specific and/or less of a hack.

[smcv]

The security advantage would be the Principle of Least Privilege. In other words, why punch a bigger hole in the sandbox than is necessary?

What integrity, confidentiality or availability property are you aiming to provide by limiting the sandbox's access to a /usr directory to which it does not have write access anyway?

The closest thing I can see is that you could argue that access that being able to know what software is installed on the host system can be used for fingerprinting (which is a minor attack on confidentiality); but there are many, many other ways to identify a host system (machine ID, network interfaces' MAC addresses, IPv4/IPv6 address, hostname, list of available fonts).

in my project we are looking at various methods of getting flatpaks to work with hardened_malloc

As I said on #5617, taking arbitrary code from the host OS distribution and injecting it into processes running inside the Flatpak sandbox is not something Flatpak aims to support, because library code from the host OS can legitimately have dependencies on host OS libraries that are not available (too old, or don't exist at all) inside the sandbox. A large part of the point of Flatpak is that the app runs in an environment that is independent of the host OS, so that as much as possible, if it works on its maintainer's machine, it will work everywhere.

If you want to replace the malloc() used by Flatpak apps, the way to achieve that is to talk to the maintainers of the runtime that provides glibc (in practice that means the freedesktop.org SDK, which is the basis for the other widely-used runtimes like GNOME and KDE) about either applying the replacement malloc() to everything, or providing an extension point by which a replacement malloc() can be hooked into it as a Flatpak extension. A Flatpak extension is a special mini-runtime which acts like a plugin for a larger runtime or app: for example, the Mesa and Nvidia OpenGL/Vulkan drivers are extensions.

[qoijjj]

@smcv greatly appreciate your input on this, that makes complete sense. I'll pursue a thread with freedesktop requesting the extension functionality you mentioned. Thanks again for pointing me in the right direction.

[qoijjj]

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1680