3 ms·
> seccomp-bpf doesn't let you follow pointers, so you can't even implement most pledge() restrictions in it. That's not even the least of it, it's impossible t
by brynet 8y ago
> seccomp-bpf doesn't let you follow pointers, so you can't even implement most pledge() restrictions in it.
That's not even the least of it, it's impossible to implement the ratcheting down semantics of pledge() using seccomp-bpf. For example, an initial pledge("stdio rpath") may be later reduced to pledge("stdio").
"Subsequent calls to pledge can reduce the abilities further, but abilities can never be regained."
- cyphar 8y agoPersonally I don't think pledge()'s semantics are the best idea in the world, especially since all of the restrictions are cleared on exec() if it is permitted IIRC -- so it's useless for sandboxing.
- brynet 8y agoOf course. If you promise "exec", then you're allowed exec. This allows pledge to be in software that otherwise would be impossible, for example text editors, and other shells. It still reduces attack surface, as the shell itself can no longer open sockets, or random device ioctls. The alternative is no protection at all. https://man.openbsd.org/pledge https://man.openbsd.org/pledge See also execpromises, which addresses your issue.