I’m using Steam/Lutris/Heroic Flatpak with Flatseal as a simplistic way of trying to increase security & privacy when playing games as I’m concerned about games being able to access, mess with & spy on things outside of the sandbox.
I’ve restricted access to certain files so they can’t access all system files or the home folder but one thing I don’t understand well enough is the “allow=devel” flag which allows syscalls. I’ve already done some reading about this and I get that it enables the use of syscalls such as “ptrace” & “perf_event_open” which can be used to monitor & even modify other processes. But what I don’t get, is can it monitor things which are running outside of the Flatpak sandbox itself, or can it monitor only what’s running inside of the Flatpak sandbox?
Also, can syscalls be used to bypass the file permission settings?
I can’t seem to find a clear answer on this and the ones I have found are from years ago and may not be relevant anymore so I’m hoping you guys can help clear this up.
I’m just a regular end user, not a developer, so please answer in laymans terms.
The Flatpak --devel flag does not grant access to external host processes or change the private /proc process isolation of the sandbox; instead, it lifts specific seccomp system call filters to allow debugging and profiling tools access to processes inside the sandbox**. [1, 2, 3]
System Calls Enabled by --devel
ptrace(): Allows process tracing, manipulation, and debugging (enabling tools like gdb or strace to attach to programs running inside the sandbox).
perf_event_open(): Allows performance monitoring and CPU profiling (enabling tools like perf). [1, 2, 3, 4]
What it does not do
It does not give the sandbox visibility into host processes outside the container; /proc remains private and restricted to the app’s own namespace. [1]
It switches the runtime environment to include developer SDK tools if available, but it fundamentally acts as a permission modifier for tracing and profiling internal application threads
I got a similar, generated response from a search engine but I know how unreliable these things can be as they mix together information from unrelated/very loosely related topics (some of which is incorrect regardless) so I didn’t want to chance it incase it was wrong.
this is something you probably need to ask flatpak developers on their github/gitlab or mailing list and whatnot.
And I mean the people developing the flatpak system, not the people on flathub (which are packagers)
Syscalls, in general, are a standard interface used by programs to interact with the kernel and, in general, are required to interact with anything outside the process’s own memory. All read/write/open/etc operations are syscalls under the hood. So in principle a syscall itself cannot be used to “bypass the file permission settings”… unless there’s a bug/exploit.
I’m not a flatpak developer, but reading the docs I do see those are the main two syscalls noted as being allowed by the alternate seccomp profile.
I wouldn’t worry about the “devel runtime”, as that’s just allowing the developer to specify which runtime version to use when debugging. The syscalls are the concerning part.
-d, --devel
Use the devel runtime that is specified in the application metadata instead of the regular runtime, and use a seccomp profile that is less likely to break development tools.
The devel feature allows the application to access certain syscalls such as ptrace(), andperf_event_open().
I haven’t reviewed the syscalls extensively, but I don’t see that they would natively bypass your file permissions settings, however they are still considered high risk.
Ptrace has had several exploits in the past that have allowed privilege escalation, which could lead to your system being compromised.
The perf_event syscalls are also potentially risky and are called out by the Linux kernel team as being so.
In short, there’s a reason those syscalls are prevented in the default seccomp profile. Other projects, such as Docker, also prevent them by default to prevent privilege escalation on the host system.
If a person or application is asking you to allow devel mode, I would seriously question why. It’s for development debugging, not for active use of the application.
Unless you’re actively developing a flatpak, leave it off imo. It would only serve to increase your exposure without any real benefit to you, the end user.
allow=devel lifts Flatpak’s seccomp filter for ptrace and perf_event_open, but each app still runs in its own PID namespace. Processes outside the sandbox aren’t visible from inside it, so ptrace can only attach to processes the game or launcher started itself. perf_event_open takes a process ID the same way, and system-wide monitoring also needs kernel.perf_event_paranoid set to 0 or lower or the CAP_PERFMON capability, which Flatpak apps don’t get. Neither syscall opens files, so your Flatseal filesystem restrictions still apply. The permissions that do reach outside the sandbox are filesystem=host, talk-name=org.freedesktop.Flatpak (it lets the app run commands on the host through flatpak-spawn), and socket=session-bus. Run flatpak info --show-permissions com.valvesoftware.Steam to see which of those each app has.
So in theory it sounds like they shouldn’t be able to see outside of the sandbox assuming no exploits are used, or is that not the case?
I get that they can be exploited though which is one reason I’m not keen on allowing the option. However, a lot of games won’t work without it enabled.
Yes. Without a kernel exploit, a game with allow devel can only trace or profile processes inside its own sandbox. Keep the kernel updated, since the ptrace privilege escalation JackTL linked was fixed in a kernel update. Also run sysctl kernel.yama.ptrace_scope on the host. A value of 1 limits ptrace to a process’s own children.
Okay. Well I ran sysctl kernel.yama.ptrace_scope and mine is set to 0 which is apparently the least restrictive setting. It looks like that’s quite common for compatibility reasons though so I’m not sure I should change that, though any advice on this would be appreciated..
My main concern is these Flatpaks as any software I don’t trust so much, namely closed source & Windows software run via WINE, is run in a Flatpak to try and restrict what it can access and do.
I’d set it to 1, since it also covers software you run outside Flatpak. Ubuntu has shipped 1 as the default for years, and the main thing it stops is attaching a debugger like gdb -p to a program that’s already running without sudo. Put kernel.yama.ptrace_scope = 1 in /etc/sysctl.d/10-ptrace.conf, then run sudo sysctl --system to apply it.
Yeh I ended up doing that so we’ll see how this goes..
And for anyone else who’s interested in doing the same - You can make a configuration file which instead of overriding the entire original configuration file, will instead just override any specific settings you’ve set in your new file and nothing else. I based my instructions on the info found in this file: /etc/sysctl.conf
Here’s my instructions (Feel free to make corrections if I’ve gotten anything wrong!):
Navigate to: /usr/lib/sysctl.d/
Copy the file: 10-default-yama-scope.conf
Paste it into: /etc/sysctl.d/
Edit the file to reflect desired changes.
This file will completely override the original file it was copied from in: /usr/lib/sysctl.d/
To make it only override some specific settings only, edit its contents so that it only has entries for things you want to change and no entries for things you don’t want to change (even if they’re unedited from the original file).
Next, rename the file to have a higher number in the filename. So for example, “20-default-yama-scope.conf”.
Reboot or run: sudo sysctl --system
This will reload kernel parameters from configuration files.
To confirm your changes, run: sysctl kernel.yama.ptrace_scope
