Interesting article, but it compares apples to a fruit stand: The approach could be improved by comparing Capsicum to using seccomp in the same way.
Sometime ago I wrote a library for a customer that did exactly that: Open a number of resources, e.g., stdin, stdout, stderr, a pipe or two, a socket or two, make the seccomp calls necessary to restrict the use of read/write/etc. to the associated file descriptors, then lock out all other system calls - which includes seccomp-related calls.
Basically, the library took a very Capsicum-like approach of whitelisting specific actions then sealing itself against further changes.
This is a LOT of work, of course, and the available APIs don't make it particularly easy or elegant, but it is definitely doable. I chose this approach because the docker whitelist approach was far too open ended and "uncurated", if you will, for the use-case we were targeting.
In this particular case, I was aided by the fact the library was written to support the very specific use-case of filters running in containers using FIFOs for IPC, logging, and reporting: Every filter saw exactly the same interfaces to the world, so it was relatively easier to lock things down.
Having said that, I wish Linux had a Capsicum-equivalent call, or, even better for the approach I took, a friendlier way to whitelist specific calls.
Landlock right now doesn't offer a lot for things that aren't file system access. Other than that it's great, you can have different restrictions per-thread if you want to.
I've seen AI written blog posts before, but this is one step above: the entire blog (~90 articles) have been AI generated over the past three months.
I already find it very frustrating that most open source projects spawning on HN's front page are resume-boosting AI slop but if blogs start being the same the internet is definitely dead.
Edit: it doesn't even looks like it's resume-boosting in this case, the “person” behind it doesn't even appear to exist. We can only speculate about the intent behind this.
It is getting more difficult to research now. Increasingly I just grab the source code locally and don't bother with the browser. Every search returns pages of wordy AI generated docs. At best they restate the code. At worse they read like badly written brochures. I am avoiding any project that doesn't have a long history. Large, feature packed projects that appeared out of nowhere on github with a single commit with no history or users are essentially stolen code that has been machine translated to obscure the original authors works.
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.
The person https://www.linkedin.com/in/vvoss/ seems to exist, I even have a mutual linkedin connection. What makes you think the “person” behind it doesn't even appear to exist?
One question I've always had about these capability systems is: why isn't there a way to set capabilities from the parent process when execing? Why trust a program to set its own capabilities? I know that having a process set capabilities on itself doesn't break existing tools, but it seems like if you really wanted a robust system it would make sense to have the parent process, the user's shell for example, set the capabilities on its children, and have those capabilities be inheritable so the child could spawn other processes with the same or fewer capabilities (if it's allowed to do that at all). Is there an existing system that works this way, in or outside of the UNIX family? Or maybe some research paper written on the subject? I'd love to know.
You can mostly do that with Seccomp on Linux (I have no experience with FreeBSD).
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
I am less sure about the others (capsicum, seccomp) but the threat model for opebsd's pledge is not that you don't trust the process, you do trust the process, otherwise you would not be running it. The threat pledge is trying to solve is where if the process gets corrupted by a malicious agent while it is running the fallout is minimal. Under this threat model the process notifies the kernel to shed capabilities as soon as it no longer needs them. something that can only be done in process.
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)
EDIT: Article seems to have been updated to remove mention of Chromium.
This article contains a lot of errors, for example Chromium on FreeBSD does NOT use Capsicum, it never has. That was experimental and invasive work done 17 years ago that was NEVER committed to their official ports repository. In fact, not a single browser on FreeBSD uses Capsicum or any form of sandboxing _at all_.
Contrast that with OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Both are enabled by default. Mozilla Firefox ports also use both pledge and unveil since 2018-2019, with refinements over the years.
OpenBSD's fork of tcpdump has been privsep for ~22 years, and its packet parser runs with no privileges. It's pledged tightly "stdio" and has no network/filesystem access, and uses OpenBSD specific innovations like bpf descriptor locking (BIOCLOCK) missing from both FreeBSD/Linux tcpdump today (despite FreeBSD adding the ioctl in 2005).
In the years since it was added, the reason Capsicum has only been applied to a handful of utilities is because it's a tree barren of decades worth of incremental work on privilege separation and security research.
No. SELinux is based on the Linux Security Module framework, which places explicit hooks at key points within the kernel.
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.
subtraction vs filtration is the right framing even if the article is slop. removing capabilities is structurally different from filtering syscalls because the set of things to filter grows every kernel release but the set of things a process actually needs doesn't.
17 comments
[ 3.8 ms ] story [ 42.0 ms ] threadSometime ago I wrote a library for a customer that did exactly that: Open a number of resources, e.g., stdin, stdout, stderr, a pipe or two, a socket or two, make the seccomp calls necessary to restrict the use of read/write/etc. to the associated file descriptors, then lock out all other system calls - which includes seccomp-related calls.
Basically, the library took a very Capsicum-like approach of whitelisting specific actions then sealing itself against further changes.
This is a LOT of work, of course, and the available APIs don't make it particularly easy or elegant, but it is definitely doable. I chose this approach because the docker whitelist approach was far too open ended and "uncurated", if you will, for the use-case we were targeting.
In this particular case, I was aided by the fact the library was written to support the very specific use-case of filters running in containers using FIFOs for IPC, logging, and reporting: Every filter saw exactly the same interfaces to the world, so it was relatively easier to lock things down.
Having said that, I wish Linux had a Capsicum-equivalent call, or, even better for the approach I took, a friendlier way to whitelist specific calls.
https://news.ycombinator.com/item?id=47268574
On Linux I understand that Landlock is the way to go.
I already find it very frustrating that most open source projects spawning on HN's front page are resume-boosting AI slop but if blogs start being the same the internet is definitely dead.
Edit: it doesn't even looks like it's resume-boosting in this case, the “person” behind it doesn't even appear to exist. We can only speculate about the intent behind this.
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.
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
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)
This article contains a lot of errors, for example Chromium on FreeBSD does NOT use Capsicum, it never has. That was experimental and invasive work done 17 years ago that was NEVER committed to their official ports repository. In fact, not a single browser on FreeBSD uses Capsicum or any form of sandboxing _at all_.
https://github.com/rwatson/chromium-capsicum
https://www.freshports.org/www/chromium/
https://cgit.freebsd.org/ports/log/www/chromium/Makefile?qt=...
Contrast that with OpenBSD, where the Chromium port has used pledge(2) since January 2016, and unveil(2) since 2018. Both are enabled by default. Mozilla Firefox ports also use both pledge and unveil since 2018-2019, with refinements over the years.
https://marc.info/?l=openbsd-ports-cvs&m=145211683609002&w=2
https://marc.info/?l=openbsd-ports-cvs&m=153250162128188&w=2
OpenBSD's fork of tcpdump has been privsep for ~22 years, and its packet parser runs with no privileges. It's pledged tightly "stdio" and has no network/filesystem access, and uses OpenBSD specific innovations like bpf descriptor locking (BIOCLOCK) missing from both FreeBSD/Linux tcpdump today (despite FreeBSD adding the ioctl in 2005).
In the years since it was added, the reason Capsicum has only been applied to a handful of utilities is because it's a tree barren of decades worth of incremental work on privilege separation and security research.
Also, what is well-known piece of software that uses Capsicum on FreeBSD ? Can someone name a few ?
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.