4 ms·

Wonder how hard it would be to provide a Pledge API which simply passes through to seccomp.

• ori_b 8y ago
  It's possible, but it's fairly hard. You'd need a second process to supervise the seccomp'ed process, watching the paths that it accesses with ptrace, and allows/disallows the actions based on inspection of the process state. The problem is that seccomp, as far as I'm aware, does not provide you with easy access to the actual arguments of system calls if they are not pointers. The actual pointed-at values of the arguments are required for emulating pledge.
  • Ua2Reemo 8y ago
    Yeah, the seccomp limitation that it can't deref pointer arguments makes things a lot less elegant than pledge. But at least unveil can be implemented via mount namespaces.
  • cyphar 8y ago
    The need for ptrace is soon going to change with the new seccomp userspace notification API (still undergoing review) which allows a userspace process to get notifications when seccomp is tripped and decide what the return code of the syscall is (you can also give it an fd which is copied to the process unix socket style). This would allow you to use process_vm_{read,write}v without the need to mess around with PTRACE_SEIZE. The main usecase for this is container runtimes (emulating privileged operations like auto-loading of kernel modules), but it could also be used for this an a whole host of other really neat features. (Huge shout-outs to Tycho Anderson for working on this for quite a while!)