Permission to read system processes? Will it ever be added?

[ecabott]

For example discord cant detect running games.

[ssokolow]

If so, I think it'd also make sense to allow an application to track which window has focus, for sandboxing things like a time-tracking app.

(I proposed this before somewhere but it was shot down as "grant once, then remember permissions doesn't have the right security dynamics for a portal"... something I now know to be a double-standard, given that I'm still trying to figure out how to forcibly revoke all persistent Open/Save grants for the Documents portal when an application exits.)

[rowbawts]

Any thoughts on this? I would really like to see OP's example addressed.

[smcv]

It is unlikely that unmodified applications are ever going to be able to read a list of system processes from /proc.

The reason apps like Discord cannot see system processes in /proc is that Flatpak runs each app in a separate process ID namespace (pidns), and each pidns gets its own private copy of /proc that only includes its own processes. This is all-or-nothing: we can create a new pidns, or we can stay in the same pidns as the rest of the system, but there is no third option.

We cannot (generally) stay in the same pidns as the rest of the system, because the new pidns is part of how we sandbox apps. Apps with the same user ID in the same pidns can send each other SIGKILL, read each other's command-line arguments and environment variables, and potentially use ptrace to remote-control each other, obtaining arbitrary code execution. None of these are things we normally want happening across a sandbox boundary.

A portal to list system processes in a way that is not "read them from /proc" would be a feature request for xdg-desktop-portal, not Flatpak itself. flatpak/xdg-desktop-portal#304 is similar, although not exactly the same thing. However, even if xdg-desktop-portal had that feature, Discord would have to be modified to use it (which we cannot do, because it is proprietary software - we can only ask its developers to make that modification).

[gasinvein]

@smcv If private /proc is there only for security reasons and isn't required for the sandbox to function, maybe shared pidns can be an opt-in permission? E.g. with some finish-arg like --share=pid (I guess this'll require some work on bwrap side).

[rowbawts]

Well when I go to the game activity section on Discord to manually add a process as a status it lists my browser Microsoft Edge? How does it see that?

[smcv]

when I go to the game activity section on Discord to manually add a process as a status it lists my browser Microsoft Edge? How does it see that?

I don't know. Maybe it's listing X11 windows, rather than processes? If you run some 1980s X11 application like xeyes or xterm, can it see those?

[chergert]

Another use for a --share=pid style option would be for profiling of applications in Builder (which is already doing a lot to break through the sandbox for development purposes anyway).

For example, if a user has built and is running their program from Builder, we may be profiling it. Some profiler bits are LD_PRELOAD (such as malloc tracing). If we can't use a global pid namespace, we can't correlate tracing data from the user project to address mappings for symbolizing.

Being able to --share=pid would mean we can be certain that the profiled process PID matches what we'd get elsewhere from systems like Linux perf's pid field of sample records, mmap events, etc.

Edit I should also note that Builder would only need it on flatpak build, not flatpak run since applications are built/incrementally run using flatpak-spawn --host flatpak build ....

[swick]

OP really only wants to introspect running apps. IMO an API to introspect applications, windows, workspaces as well as allowing apps to change workspaces, stacking order, focus, window positions, etc would be the right move here.

Sharing the pidns is something completely different. Maybe open a new issue?

[llothar]

The real solution is to make the whole sandboxing opt-out and let flatpak also work just as a package distribution tool.

[ssokolow]

The real solution is to make the whole sandboxing opt-out and let flatpak also work just as a package distribution tool.

That'd be harder than it sounds because Flatpak's means of exposing its runtimes to packages is fundamentally based on containerization.

For example, aside from a little blacklisting, --filesystem=host is already akin to how Wine exposes your / at Z: by default.

[ghost]

To say, letting this API exist won't weaken security much. If you can execute programs on host (using flatpak-spawn) or even write to home directory (and change shell init scripts, desktop entries) you already can do all of that.

For example Mission Center in order to read processes spawns an agent on the host and having an D-Bus API for process management (but that is a matter of portals), or share the namespace would be useful for this kind of app, otherwise they will have to do these hacks or they will just not work. of course for this kind of apps having a write access (to send signals) would be useful too.

[llothar]

The real solution is to make the whole sandboxing opt-out and let flatpak also work just as a package distribution tool.

That'd be harder than it sounds because Flatpak's means of exposing its runtimes to packages is fundamentally based on containerization.

I mean all the additional security features of sandboxing.

And well the runtime part needs a huge change too. It's insane that a program needs a full runtime even if it just uses a fraction of files from it. When Flatpak ages and we start seeing more and more older not maintained apps anymore then the number of installed runtimes will significantly go up. The runtime needs to just install what it needs.

Just treat it like a virtualized non updateable linux distribution.