5 ms·

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

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/f6114bd1df371047dd80ea9b8a55c104 https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55...

trasz 8y ago
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 8y ago
  > The difference is that while Capsicum provides you with very solid, ... ... That nothing uses. And even their flagship research example, Chrome, has never made it into the FreeBSD ports tree. OpenBSD has pledge(2)/unveil(2) for Chrome.
  - trasz 8y ago
    Not true - Capsicum is used by a growing amount of software, from base system utilities (like uefisign(8)) or servers (like ctld(8)) to third party stuff, like Irssi. And yes, there are language bindings as well. The problem with Chrome is not that it’s hard to capsicumize - it’s not, it has been done and documented - but rather that the upstream developers are extremely uncooperative wrt accepting patches.
    - notaplumber 8y ago
      Huh? FreeBSD has never included the Capsicum patches for chromium in ports. Google not accepting this upstream is a separate issue, albeit regretful, OpenBSD maintains the pledge/unveil patches and users benefit from this work today, whereas FreeBSD users cannot run Capsicum-ised Chrome. Capsicum patches are also considerably more intrusive, and their intention and protection is less clear.
  - OpenBSD-reich 8y ago
    You're getting heavily downvoted. Obvious FreeBSD shill army is obvious! I really appreciate Theo's approach to operating system security, and the ecosystem as a whole is very much indebted to the OpenBSD project for its advancements.
- notaplumber 8y ago
  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 8y ago
    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 8y ago
      > 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.
- toast0 8y ago
  I haven't tried to pledge any software, but I did try to capsicum a proxy daemon, which I wasn't able to do, because there isn't a reasonable way to limit everything, except for networking. I would have had to move socket creation into a different (unsandboxed) process and then pass the sockets around to the proxy worker processes. This is doable, but a lot of work and could impact performance, so I ended up not doing it; the process was already running as a statically linked binary non-root in a jail with no other executables, but it would have been nice to remove more things.
kev009 8y ago
You are overestimating technology and underestimating organization. OpenBSD is a tightly nit (at least philosophically) group with a single leader. FreeBSD is a loose federation of large commercial users, academics and industrial researchers, and end users with a broad range of needs and a bureaucratic core team without any one leader. Let's buy your comment and say Capsicum is harder to use. Let's hypothetically say it takes twice as long to implement in an application. The FreeBSD community could easily absorb that cost, but there is nobody with earned or assumed authority pointing people in the direction to achieve that high base coverage. As in the original article, the author is doing this in his spare time and there are only a couple other people that assist occasionally. On the other hand Theo has made it a point to achieve high coverage, and quickly, for OpenBSD's new APIs. The sandboxing functionality is philosophically important to most of the OpenBSD organization, and only seen as important to a small subset of FreeBSD's heavy movers. So that is why you see much lower application coverage.
- emmelaich 8y ago
  nit: it's knit not nit

trasz 8y ago

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 8y ago
> The difference is that while Capsicum provides you with very solid, ... ... That nothing uses. And even their flagship research example, Chrome, has never made it into the FreeBSD ports tree. OpenBSD has pledge(2)/unveil(2) for Chrome.
- trasz 8y ago
  Not true - Capsicum is used by a growing amount of software, from base system utilities (like uefisign(8)) or servers (like ctld(8)) to third party stuff, like Irssi. And yes, there are language bindings as well. The problem with Chrome is not that it’s hard to capsicumize - it’s not, it has been done and documented - but rather that the upstream developers are extremely uncooperative wrt accepting patches.
  - notaplumber 8y ago
    Huh? FreeBSD has never included the Capsicum patches for chromium in ports. Google not accepting this upstream is a separate issue, albeit regretful, OpenBSD maintains the pledge/unveil patches and users benefit from this work today, whereas FreeBSD users cannot run Capsicum-ised Chrome. Capsicum patches are also considerably more intrusive, and their intention and protection is less clear.
- OpenBSD-reich 8y ago
  You're getting heavily downvoted. Obvious FreeBSD shill army is obvious! I really appreciate Theo's approach to operating system security, and the ecosystem as a whole is very much indebted to the OpenBSD project for its advancements.
notaplumber 8y ago
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 8y ago
  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 8y ago
    > 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.
toast0 8y ago
I haven't tried to pledge any software, but I did try to capsicum a proxy daemon, which I wasn't able to do, because there isn't a reasonable way to limit everything, except for networking. I would have had to move socket creation into a different (unsandboxed) process and then pass the sockets around to the proxy worker processes. This is doable, but a lot of work and could impact performance, so I ended up not doing it; the process was already running as a statically linked binary non-root in a jail with no other executables, but it would have been nice to remove more things.

kev009 8y ago

You are overestimating technology and underestimating organization. OpenBSD is a tightly nit (at least philosophically) group with a single leader. FreeBSD is a loose federation of large commercial users, academics and industrial researchers, and end users with a broad range of needs and a bureaucratic core team without any one leader. Let's buy your comment and say Capsicum is harder to use. Let's hypothetically say it takes twice as long to implement in an application. The FreeBSD community could easily absorb that cost, but there is nobody with earned or assumed authority pointing people in the direction to achieve that high base coverage. As in the original article, the author is doing this in his spare time and there are only a couple other people that assist occasionally. On the other hand Theo has made it a point to achieve high coverage, and quickly, for OpenBSD's new APIs. The sandboxing functionality is philosophically important to most of the OpenBSD organization, and only seen as important to a small subset of FreeBSD's heavy movers. So that is why you see much lower application coverage.

emmelaich 8y ago
nit: it's knit not nit