4 ms·

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 reex

by 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.

by 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.