1. 15
  1.  

  2. 5

    It makes me so sad that the Linux community rejected Capsicum. Every time I want to write sandboxed software, I end up with something that’s trivial to implement in Capsicum and requires me to jump through huge numbers of hoops to get right in Linux.

    1. 4

      Capsicum was pretty cool, and cool to see folks remember it. I myself, hadn’t thought about it in ages.

      Every time I want to write sandboxed software,

      Do you do this often? I have been trying to find the right tooling for this and plain old containers ain’t it. Do you have thoughts or recommendations? Also curious to know if you have thoughts on the heavier-weight solutions based on LSM like SELinux and AppArmor!

      1. 3

        Do you do this often?

        Yes, although I’m probably an outlier here.

        I find capabilities the right tool for reasoning about this kind of thing and Capsicum gives exactly the thing I want: I can create a child process that explicitly has only the rights that I give it. None of the Linux (or Windows) things make dynamic policies easy. For example, I want to create a sandbox and grant it access to a file based on some user interaction. With Capsicum, that’s trivial, because I can just implement open in my child process and any library call to open I then proxy to an RPC to the parent that validates the path and hands back a file descriptor. If I want to grant read-only access, I can strip write permission from the file descriptor before I return it and know that nothing can elevate that privilege. Similarly, if I want to share memory but guarantee that the child can only read from it, I can pass a file descriptor that has only the CAP_MMAP_R permission and know that the only thing that the child can do is map it read-only.

        The macOS sandbox framework approximates Capsicum on top of the TrustedBSD MAC framework (which macOS and FreeBSD share) by dynamically updating a per-process ACL as the program runs. Rather than requiring the powerbox to pass a file descriptor into the sandboxed process, it instead updates the sandboxed process’s ACL so that it is allowed to open the file. That’s a bit less disruptive on the APIs but it means that you have to be really careful about things like filesystem manipulation (if I move a file to another directory, should the sandboxed application be able to access it? Probably. If I create a new file with the same full path as the now-moved file, should the sandbox be able to access it? Probably not).

        I am quite tempted to write a Linux module that provides a /dev/capsicum that lets you create wrapper file descriptors that have limited rights and a seccomp-bpf policy that denies all system calls that are not on the Capsicum-allowed list. Software using it would have to do an ioctl on their /dev/capsicum fd instead of openat, but it might be sufficient.

    2. 2

      This article was rather refreshing to read, as much as I love using linux, it’s nice to read both pros and cons of the platform while being able to recognise the good stuff of other ones.

      1. 2

        The author also has written an incredibly detailed list of things you can do to harden your linux box here: https://madaidans-insecurities.github.io/guides/linux-hardening.html

        Reading it is an excellent reminder of just how much stuff is in the kernel these days.