top | item 44574995

(no title)

poolpOrg | 7 months ago

I may be biased but the OpenBSD approach with pledge() and unveil() have been my favorite sandboxing mechanisms of all time due to their simplicity: pledge has really understood that as a developer I want to whitelist an intention, not a specific set of syscalls and options, and unveil is chroot on steroids <3

discuss

order

wahern|7 months ago

Theo was recently proposing a new flag to open, O_BELOW: https://undeadly.org/cgi?action=article;sid=20250529080623

It's like Linux's RESOLVE_BENEATH flag to openat, except it's a constraint placed on the directory descriptor itself so that subsequent opens using openat(2) cannot reach anything outside the subtree. Which seems like exactly the semantics you'd want for a capability system. In FreeBSD Capsicum mode, this behavior is enforced implicitly[1], but it'd be a nice thing to have explicitly to help incrementally improve code safety.

[1] See https://man.freebsd.org/cgi/man.cgi?open(2)#:~:text=capsicum...

wahern|7 months ago

Seems FreeBSD beat OpenBSD to the punch with something similar, FD_RESOLVE_BENEATH, committed only a couple of weeks ago.[1] Seems the idea was conceived before the OpenBSD proposal, and it differs subtly by attaching to the file descriptor rather than the file description (aka file table entry), though unlike the other file descriptor flags (FD_CLOEXEC, FD_CLOFORK) it's hacked to be inherited across dup, behaving more like file table entry flags (access mode, O_NONBLOCK, etc).

[1] https://reviews.freebsd.org/D50371