OpenBSD's Pledge and Unveil from Python

Or using API-mode cffi which basically does that for you, though it’s still not quite safe you can combine `cdef` and `set_source` to re-export exactly what you’re looking for. `set_source` will basically create an intermediate module under your control.

Sadly AFAIK you always need a `cdef` which defines the binding between Python and C, I don’t think you can tell cffi to get this information from a real header file. But by providing a custom source you can more easily ensure the `cdef` and the function for it match correctly, with `set_source` bridging to the real underlying functions.

One drawback of using API-level CFFI is it requires a C compiler (and probably all sorts of dev packages / headers), whereas ABI-level use doesn’t.

I would check to make sure I was running on an OpenBSD system first before anything else.

You could use sys.platform()

https://docs.python.org/3/library/sys.html#sys.platform

I upvoted, but I wanted to correct a small thing.

> ...they are mostly hopeless to try to apply to portable software after the fact if the devs aren't constantly testing with it.

They don't have to be hopeless. They were pretty easy ([1], [2]) to add to my bc.

[1]: https://git.yzena.com/gavin/bc/commit/3e8cd345de9d5b65ac7c33...

[2]: https://git.yzena.com/gavin/bc/commit/b6c65bb44c910c054bedfa...

Seccomp profiles are typically applied externally to a process in my experience though. I think this is more analogous to using capset() to remove capabilities in highly permissioned processes. For instance dnsmasq makes use of this ability to be minimally permissioned.

> At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec?

The validity of that criticism is so-so. It's a common complaint from people who are trying to build an externally imposed sandbox that dictates what a program can do.

But that's not what pledge and unveil are. They're more of an internally imposed set of constraints: the program just announces what it's going to do. After that, if it breaks the contract (due to a bug or malicious intervention), the system has license to kill it.

The program knows what it is going to do, so it can write the contract for itself. But it doesn't know what some other program is going to do, so it doesn't make sense for these restrictions to persist after exec. The program-to-be-exec'd should have its own pledges.

In reality it's even more complicated than that: programs often need to perform some "privileged" operations before they are ready to put on their straight jacket. It'd be very hard for program A to say that program B starts with privileges X, Y, Z, and then after instruction Q drops Y and Z. And program B might require more privileges than what A had when it called exec, so again it's just not going to work for this at all. If A's privileges were to persist, then it would have to have some way to elevate them or it'd never drop them in the first place. Both seem like a bad deal.

It's just a completely different mechanism, but people think sandbox sandbox sandbox and if that's all one can think of, pledge and unveil might seem like a terrible tool for that. They're not a tool for sandboxing untrusted programs.

> Freebsd has capsicum which, like seccomp (mentioned else-thread) is much more complex and flexible.

Capsicum may be more flexible in some ways, but it's also less flexible in others.

After you a process entera capsicum mode, it can't open new sockets, except by accepting on an existing listen socket or by receiving them on a unix socket, sent by a cooperating non-capsicum process. This means you can't capsicum a TLS proxy like hitch, which would be a great thing to capsicum since the operation is pretty simple and OpenSSL is scary.

A major limitation of seccomp is that you can't turn off inheritance. With pledge inheritance is opt-in.

This has major consequences because it makes it possible for a process to secure itself without affecting its ability to spawn child processes. You could apply seccomp in-process or use a spawn-helper before securing it. But more realistically it means that one applies an external seccomp profile to a group of processes (e.g. a container) that contains the union of all needed syscalls.

So while seccomp is more flexible in some sense (being able to run BPF filters on every syscall) its architecture leads to it being applied in a less flexible way.

> Pledge/unveil are manifestly more successful, being used pervasively (though not really by programs which do not primarily target openbsd).

Because of their simplicity, they are easily added as a patch to a ported application. There are probably more ports using them than programs that target openbsd.

It really doesn't make much sense to compare pledge/unveil to seccomp and capsicum or any other sandboxing solution.

Pledge and Unveil are really part of the program's specification. They are much closer in practice to asserts, pre-conditions, or contracts depending on the programming language you have used. They basically make sure that the program you are writing doesn't do anything stupid with bad inputs from the outside world. Its part of the development process, and not very hard to add to an existing program.

Would be useful to have a unified API…