Hacker News new | ask | show | jobs
by lmns 1888 days ago
I know, but just setting MemoryDenyWriteExecute=yes is even easier.
1 comments

I’m not an active OpenBSD user, but I’m reasonably confident that the OpenBSD W^X check kills any violating process since about 2016. Applies to all executables (not just system services/daemons with conscientious maintainers who think to apply that setting) except if the filesystem is mounted wxallowed. I think that’s a strict improvement.

I like systemd on Linux, but I think the systemd sandboxing is chasing OpenBSD, not the other way around.

Doesn't systemd's sandboxing do seccomp-bpf? Pledge is an interesting system, but it's not BPF.
systemd’s syscall filtering is pretty good and comparable to pledge in terms of ease of use — both let you use nice aliases for sets of syscalls, like stdio or @aio. I’ve only _played_ with both, so my opinions are weakly held, but pledge+unveil excel for designing a system where I have full source code control/authorship, and systemd’s sandbox excels for deploying third party services. pledge+unveil just make it so easy to incrementally drop privileges after your initialization phase(s), where for systemd, so far as I know, you’d have to have separate service files for the smaller sandboxes of subsequent phases — or better yet, use seccomp-bpf directly, or even better... a pledge-like wrapper on top.

Ideally your app wouldn’t need any more syscalls at startup than it needs later on though, so it’s quite legitimate to argue it’s no big deal at all, or that systemd encourages better design discipline.