Hi,
I’m curious about how snapd handles child process security policy, especially seccomp. My understanding is that child processes inherit the parent’s seccomp filter and they can only make the filter more strict.
If I run a parent snap that executes another binary, and the child process uses a particular system call that the parent does not use, how is this transition handled?
Thanks
Hi!
You are correct about how seccomp works. The child inherits the parent’s filter such that if a child needs a syscall that isn’t allowed in the parent’s policy, the access is denied.
AppArmor supports something called ‘profile transitions’ with its exec rules, but within the snap policy we almost always (there is only one exception) use ‘ix’ rules, where children similarly inherit the parent’s policy.
Snaps are pretty flexible though and it is possible for you to have a daemon with one set of security policy and command with different policy that talks to the daemon, such as through a named socket in SNAP_DATA. The client could talk to the daemon over the socket and have the daemon execute code within the context of the daemon’s security policy on behalf of the command (doing this in a production snap that did anything meaningful would need to be carefully designed of course because while the daemon is confined, you wouldn’t necessarily want untrusted non-root users to trash the daemon’s data, for example).
You might be interested in:
Hope this helps!
