Capsicum support

[asomers]

FreeBSD's Capsicum facility is used to sandbox processes into a capability mode. Unable to access any global namespaces, their ability to harm the overall system is very limited. It's a terrific security feature. But the sysctl(3) functions do access global namespaces. So to use them in capability mode requires a helper: the Casper library. Once a process is in capability mode, it can use the cap_sysctl(3) facility to access sysctls. I originally attempted to implement cap_sysctl in a separate crate, but encountered difficulties. Basically, it's just way too complicated. Dealing with sysctls, as you know, requires lots of code to handle all the different data types. So instead of having a separate cap-sysctl-rs crate, I propose moving that functionality into here. If you agree, this is what I think we should do:

1. Add libcasper(3) bindings to libc, or create a separate libcasper-sys crate. I'll raise the issue with the libc team and see which they prefer.
2. Implement basic libcasper support within the capsicum-rs crate. I've already got a branch for this.
3. Add a private SysctlProvider trait to this crate with three methods: sysctlbyname, sysctl, and sysctlnametomib. Existing functions like unix::funcs::value_oid will gain a new argument, a &dyn SysctlProvider.
4. Create two implementors of this trait: NativeSysctlProvider and CasperSysctlProvider. The former will simply wrap the existing sysctl(3) functions. The latter will wrap cap_sysctl(3), and will also include methods to initialize the casper connection and configure limits.
5. Create a public CasperSysctl struct and implement the Sysctl trait for it. In order to preserve the existing API, the actual casper connection will have to be a global variable.
6. Optionally, gate all of this Casper stuff behind a feature flag. However, since Casper is only implemented on FreeBSD and all official FreeBSD releases have it, I don't think we need to add a feature flag .

What do you think? cc @dlrobertson .

[dlrobertson]

Can't speak too much to the other points, but I'm happy to aid in maintaining libcasper support in capsicum. I am curious about the benefits of adding libcasper support to capsicum vs creating a libcasper crate that depends on capsicum-rs.

[asomers]

Well, nobody will ever use libcasper without using capsicum. There are, however, plenty of use cases for capsicum that don't require libcasper. But shorn of its services, libcasper is pretty small. IMHO it doesn't require a standalone crate. What about adding it to capsicum-rs, but gated by a feature flag?

[dlrobertson]

Thanks! That makes sense.

[johalun]

Thanks for the suggestion! I like it and it seems you thought about all the questions I would have. Not a fan of the global variable for the casper connection but if it's between that and breaking the API I prefer not breaking the API.

Having it behind an target_os gate and not feature flag seems OK to me (but not for all unix since I don't think macOS/iOS has this right?).

[asomers]

Correct. Capsicum is FreeBSD only. There was a Linux port, but I don't think it's complete or currently maintained.

[asomers]

Status update: I've gotten Casper working on a different real-world project (but not cap_sysctl). But I actually no longer have a personal need for cap_sysctl, so I'm going to deprioritize that part. Currently I'm blocked by a few PRs at https://github.com/Inner-Heaven/libnv-rs/ before we can integrate this into the capsicum-rs crate.

[dlrobertson]

👍 Thanks for working on this and adding an update