
Capsicum - adamnemecek
https://oshogbo.vexillium.org/blog/57/
======
notaplumber
Capsicum is difficult to use, and has never been used to its full potential in
FreeBSD.

OpenBSD's pledge(2) and unveil(2) by comparison are seeing far greater usage,
covering somewhere between 85% to 90% of the base operating system. Patches
for 3rd party software, and programming languages are also appearing upstream,
as they also serve as helpful annotation for other mechanisms and encourage
privilege separation.

[https://man.openbsd.org/pledge](https://man.openbsd.org/pledge)

[https://man.openbsd.org/unveil](https://man.openbsd.org/unveil)

[https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55...](https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55c104)

~~~
trasz
The difference is that while Capsicum provides you with very solid, easy to
reason about protection model. Meanwhile... can you still escape the pledge by
reexecuting yourself?

~~~
notaplumber
This weak argument from FreeBSD people is getting rather tiresome.

You can only call fork/exec if it's part of the pledge(2) promises, which you
can later drop with subsequent calls to pledge. And with unveil(2) or even
chroot(2) you can also place further restrictions on which binaries can be
executed, and in which directories.

Systems like Capsicum would have you not be able to sandbox those programs at
all. Users are left unprotected. So yes, if you pledge(2) a shell. It can call
exec, but directly it can't call socket/connect(2), and the reduction of
kernel attack surface is still significant. Software using privilege
separation can safely leverage this.

~~~
trasz
Thing is, with pledge you never really know what the promises actually are, or
if they make sense, in that you cannot work around them. With Capsicum (or any
other capability system) you can.

The assumption that with Capsicum you wouldn’t be able to sandbox stuff is
blatantly false. The proof is existing code - Chromium, Tor, or Irssi - that
has been capsicumized, often much more easily than with seccmp (I’ve not seen
that comparison with pledge(2) yet).

One advantage that pledge(2) certainly has is the community involvement.
OpenBSD has applied pledge(2) in many places, while capsicum(4) was quite a
bit slower until recently. This has nothing to do with technical differences,
and more with the social aspects.

~~~
notaplumber
> Thing is, with pledge you never really know what the promises actually are,
> or if they make sense, in that you cannot work around them.

This makes no sense. Of course you know what the promises are, they're in the
source code. You can also use ktrace/kdump(1) or even strings(1). The names of
the promises are obvious and their intention is clear. There are subsets of
POSIX.

> The assumption that with Capsicum you wouldn’t be able to sandbox stuff is
> blatantly false.

That is not what I said, I was specifically correcting your misinformed
statement regarding pledge(2) and those programs that explicitly permit exec,
like shells. Capsicum has no solution for this, and as such these programs
cannot be sandboxed on FreeBSD.

~~~
markjdb
> The names of the promises are obvious and their intention is clear. There
> are subsets of POSIX.

That's true, but not really the whole truth. Take "dns", for instance. It
enables a number of system calls needed to perform DNS resolution. But as far
as I understand, those system calls (sendto(2) for example) can then be used
arbitrarily. So "dns" actually permits more than the name implies.

On the other hand, when a program is running in capability mode, we know
exactly what is permitted and what isn't.

> Capsicum has no solution for this, and as such these programs cannot be
> sandboxed on FreeBSD.

... they can't be sandboxed on OpenBSD either. pledge("proc exec") doesn't
give you a sandbox.

~~~
brynet
Hi, that is not true. The "dns" promise only allows sockets with the SOCK_DNS
option, the kernel restricts access to only DNS type operations and port
numbers (enough for libc to do DNS). The kernel tries to separate pledges as
tightly as possible, with many checks:

    
    
        SOCK_DNS
            For domains AF_INET or AF_INET6, only allow connect(2), sendto(2), or sendmsg(2) to the DNS port (typically 53).
    

[https://man.openbsd.org/socket](https://man.openbsd.org/socket)

~~~
markjdb
Ok, so that's tighter than what I said, but my point still stands.

------
2trill2spill
It's too bad Capsicum was never merged into the Linux kernel[1]. It would have
been nice to have one sandboxing API to use across the two operating systems,
and the two projects could share the effort of sanboxing existing programs and
libraries.

[1]: [http://www.capsicum-linux.org/](http://www.capsicum-linux.org/)

~~~
amluto
All it needs is for someone to finish the port.

------
trasz
One other URL that might help understanding the "big picture" behind Capsicum
is, and how it differs from most other sandboxing mechanisms, is this:
[https://en.wikipedia.org/wiki/Capability-
based_security](https://en.wikipedia.org/wiki/Capability-based_security).
(It's not _that_ good, though; someone(tm) should eventually write an article
explaining Capsicum from that point of view, since it's a pretty fundamental
difference.)

------
fulafel
Aside: patch(1) from the example is a really good candidate for isolation. A
few months ago we had this RCE:
[http://git.savannah.gnu.org/cgit/patch.git/commit/?id=123eaf...](http://git.savannah.gnu.org/cgit/patch.git/commit/?id=123eaff0d5d1aebe128295959435b9ca5909c26d)

------
rhizome
I love this, it's like the unikernel of shell security.

------
raverbashing
Apparently the author decided to not only replace all occurrences of "its"
with it's, but all occurrences of "it" as well.

~~~
loeg
The author is Polish and not a native English speaker, if that helps you
understand the grammar.

