> 1) pledge() lets you give high level "I just want to do I/O on what I
already have", and it doesn't matter if new syscalls "openat2" (should be
blocked) or "getrandom" (should be allowed) are created. (see the
`newfstatat` example on printf).
You can do this with seccomp if you're libc. A new syscall is of no
consequence for the seccomp filter unless libc starts using it, in which
case libc can just add it to the filter. (Of course the filter has to be an
allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are
released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to
it. If your dependency uses a raw syscall (and let's be honest this isn't
that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't
tell/test which ones use raw syscalls and when, you have no hope of
successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows
blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't
inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a
statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect
problems on OBSD too because pledge was not designed for that. (It can work
in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries
with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD
should have been able to make pledge/unveil a libc feature using a
seccomp-like API, or hell, implemented entirely in user space. But Linux,
which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge
is useful in." (Entirely in user space no, with seccomp yes.)
You can do this with seccomp if you're libc. A new syscall is of no consequence for the seccomp filter unless libc starts using it, in which case libc can just add it to the filter. (Of course the filter has to be an allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to it. If your dependency uses a raw syscall (and let's be honest this isn't that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't tell/test which ones use raw syscalls and when, you have no hope of successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect problems on OBSD too because pledge was not designed for that. (It can work in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD should have been able to make pledge/unveil a libc feature using a seccomp-like API, or hell, implemented entirely in user space. But Linux, which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge is useful in." (Entirely in user space no, with seccomp yes.)