FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing (opens in new tab)

Archive: https://archive.ph/rLmTq

I'm not sure what glibc's latest policy is on linking statically, but at least it used to be basically unsupported and bugs about it were ignored. But even if supported, you can't know if it under some configurations or runtime circumstances uses dlopen for something.

Or maybe once you juggle more than X file descriptors some code switches from using `poll()` to using `select()` (or `epoll()`).

My thoughts last time I looked at seccomp: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h...

Capsicum attaches rights to descriptors and gives kernel enforced primitives like cap_enter and cap_rights_limit, so delegation is explicit and easier to reason about. If you want Linux parity, use libseccomp to shrink the syscall surface, combine it with mount and user namespaces and Landlock for filesystem constraints, and design your app around FD based delegation instead of trying to encode every policy into BPF.

> Why trust a program to set its own capabilities?

An example may be that a program starts needing a wide range of capabilties but can then ratchet down to a reduced set once running, aka "privdrop".

> why isn't there a way to set capabilities from the parent process when execing?

There have been replies on other systems so just to stick with pledge which provides the abiliy to set "execpromises" to do this.

[1] https://man.openbsd.org/pledge

[2] https://www.openbsd.org/papers/eurobsdcon2017-pledge.pdf

[3] https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pd...

The way capabilities usually work is you more or less turn off the usual do whatever you want syscalls, and have to do restricted things through FDs that have the capability to do them. So like, no more open any path, you have to use openat with a FD in your directory of interest. But that requires the program to understand how to use the capabilities and how to be passed them. It's not something that you can just impose.

My understanding of SELinux, is it can be imposed on a program without the knowledge of the program, because it's more or less matching rules for syscalls... rather than giving a restricted FD to use with openat, you restrict the options for open.

Openbsd had a neat external syscall sandboxing system at one point (systrace ) it was removed for reasons I don't fully understand. But I think it boils down to "optional security isn't". hard to maintain, problematic, external policies, the first thing you do is disable them (cough selinux cough)

Child processes inherit the restrictions from the parent. You can therefore have the parent fork, setup it's rules, then exec. This is exactly how syscall filtering (and a bunch of other lockdowns) are implemented in SystemD

But I am pretty sure you CAN get your capabilities from a patent process using capsicum, since they are just file descriptors.

I hate becoming the old person shaking their fist at the sky but the AI bros have just gone too far. I don't know why there isn't a bigger political and social movement against them. I would sign up in an instant to see their companies and practices regulated out of existence.

But hey, it's a game!

They also operate under pretty fundamentally different philosophies. Seccomp is based on a program dropping its own permissions. SELinux is based on a system integrator writing an ahead of time policy restricting what a program can do.