5 ms·

Pledge is like 100% easier to understand. FreeBSD has similar stuff and it is also super complicated and basically unused.. If you can't make this idiot proof

by zie 5y ago

Pledge is like 100% easier to understand. FreeBSD has similar stuff and it is also super complicated and basically unused.. If you can't make this idiot proof, there is little hope anyone will ever use it.

V-eHGsd_ 5y ago
"make something idiot proof, and then they come along and invent a better idiot"
wahern 5y ago
Reading the documentation my guess is that landlock works similar to OpenBSD unveil, where the kernel pins and tags a dentry object. If a path walk doesn't traverse a tagged dentry object w/ an allow flag, or the most recently traversed dentry has a block flag, the open fails. That neatly avoids the need to compare paths. One caveat is that renames, particularly renames of directories, might not behave as expected from the perspective of a user specifying paths. Linux thread semantics wrt credentials are likely to be an achilles heel, though, from an exploit mitigation perspective. Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. This is one reason for the lack of seccomp uptake, and landlock is recapitulating the same mistake.
- comex 5y ago
  > Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. If subprocesses don’t inherit sandbox restrictions, can’t you trivially escape the sandbox by spawning a subprocess to do whatever work you want? What exactly are you proposing here?
  - wahern 5y ago
    This confuses two different problems. The problem most people think of is how to sandbox a specific series of functional operations they have in mind, like opening and reading a PDF file. And then they think to themselves, what kind of API would I need to restrict a PDF viewer to just the file I'm passing. But the problem for ubiquitously minimizing privileges across myriad tools (almost all OpenBSD command-line tools use pledge and/or unveil, now) is that the calling program can't make assumptions about the permissions and files a child program might need. So for example, a PDF viewer (or for the sake of simplicity, let's say a PDF text extractor) might need to access /bin/gunzip. The calling program can't know this ahead of time. So it has no way of reliably including those necessary files in its permitted set. But even if it did, without major refactoring it would end up w/ a union of the privileges it needs itself and of all the privileges its child processes might need, which is the opposite of what you're trying to achieve with privilege minimization. Ultimately, the only program that can truly know--and the only one that should be tasked with knowing--what privileges are needed to perform an operation is the program performing that operation. (And note that major refactoring, such as splitting a program into a series of interoperating processes w/ discrete privileges sets, is usually not a realistic option. If it were then solutions like Capsicum would be more than adequate. Certainly new software should try to use this approach if it can.) At the end of the day, when it comes to security you can't really save vulnerable software from itself without touching that software. Attempting to build sandboxes outside that software doesn't work well in practice. Witness SELinux, which most people disable because the rules (invariably written by people other than the authors of the programs) are too brittle and prone to breaking functionality. But neither, of course, is it practical to rearchitect all our software. The reason why pledge and unveil and their default semantics of non-inheritance work so well is that they provide an optimal middle-ground. Each program concerns itself w/ minimizing its own privileges, and relies on programs it invokes to do the same. And w/ a good API, like pledge and unveil, in a shockingly short period of time those expectations (that a child program does know how to restrict its own permissions) can be substantially met w/ minimal effort. The typical patch to OpenBSD utilities included just several lines of code spread around various critical areas. For example, open or (if you can't open immediately) unveil any file paths passed on the command-line. Ditto for extraneous resources like /bin/gzip or /etc/magic. Then drop as many other privileges as you can as soon as you can, like network access. The appropriate way to do this is always highly dependent on the function and architecture of the program. Of course, if you're a leaf program then, yes, you want restrictions to be inherited by default in case some bug permits uncontrolled invocation of a utility. But in most of these cases this can be solved by, e.g., blocking exec. As a framework matures, sure, extensions can be added for the niche cases where you want to toggle inheritance and/or pre-specify restrictions as the invoker of another program. But these features should not be the emphasis, and they definitely shouldn't be provided in lieu of interfaces for non-inherited restrictions.
- compsciphd 5y ago
  re invoking other tools: I built this years ago (if i'd do it again, I'd implement it with LSM, but was coming from a lab with lots of stackable fs experience, so my thought process went there), used exec() to transition rule sets. https://www.usenix.net/legacy/events/lisa07/tech/full_papers/potter/potter.pdf https://www.usenix.net/legacy/events/lisa07/tech/full_papers...
chalst 5y ago
> FreeBSD has similar stuff and it is also super complicated and basically unused.. Are you talking about Capsicum? It's definitely not unused. Unloved, maybe. There was a Reddit thread where some people talked about the possibility of layering pledge/unveil on top of it. https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds_jails_basically_accomplish_the_same/ https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds... Something along these lines has been done by Ryan Stone https://papers.freebsd.org/2020/bsdcan/stone-oblivious_sandboxing_capsicum_ebpf/ https://papers.freebsd.org/2020/bsdcan/stone-oblivious_sandb...
- toast0 5y ago
  Capsicum seems so useful, but some of the boundaries are so rigid. As far as I could tell, you can't capsicum anything like a TLS terminator or http proxy etc, because there's no way to allow opening new sockets after entering capabilities mode; you could have another process open up the sockets and pass the FD, but if I'm writing both the sandboxed process and the one that opens sockets, I'm not sure it makes enough difference. I ended up with jails instead, being stuck in a chroot with only a static executable, a config file, and a log file felt good enough to me.
  - trasz 5y ago
    It’s rigid, because it implements a security architecture (capability-based security) instead of providing a mechanism to implement random restrictions.
    - chalst 5y ago
      Capability-based security can be done flexibly: look at EROS and E: http://www.erights.org/related.html http://www.erights.org/related.html
- 1MachineElf 5y ago
  zie may be referring to the Mandatory Access Control implementation on FreeBSD[0], not Capsicum. [0] https://docs.freebsd.org/en/books/handbook/mac/ https://docs.freebsd.org/en/books/handbook/mac/

by zie 5y ago

V-eHGsd_ 5y ago

"make something idiot proof, and then they come along and invent a better idiot"

wahern 5y ago

Reading the documentation my guess is that landlock works similar to OpenBSD unveil, where the kernel pins and tags a dentry object. If a path walk doesn't traverse a tagged dentry object w/ an allow flag, or the most recently traversed dentry has a block flag, the open fails. That neatly avoids the need to compare paths. One caveat is that renames, particularly renames of directories, might not behave as expected from the perspective of a user specifying paths. Linux thread semantics wrt credentials are likely to be an achilles heel, though, from an exploit mitigation perspective. Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. This is one reason for the lack of seccomp uptake, and landlock is recapitulating the same mistake.

comex 5y ago
> Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. If subprocesses don’t inherit sandbox restrictions, can’t you trivially escape the sandbox by spawning a subprocess to do whatever work you want? What exactly are you proposing here?
- wahern 5y ago
  This confuses two different problems. The problem most people think of is how to sandbox a specific series of functional operations they have in mind, like opening and reading a PDF file. And then they think to themselves, what kind of API would I need to restrict a PDF viewer to just the file I'm passing. But the problem for ubiquitously minimizing privileges across myriad tools (almost all OpenBSD command-line tools use pledge and/or unveil, now) is that the calling program can't make assumptions about the permissions and files a child program might need. So for example, a PDF viewer (or for the sake of simplicity, let's say a PDF text extractor) might need to access /bin/gunzip. The calling program can't know this ahead of time. So it has no way of reliably including those necessary files in its permitted set. But even if it did, without major refactoring it would end up w/ a union of the privileges it needs itself and of all the privileges its child processes might need, which is the opposite of what you're trying to achieve with privilege minimization. Ultimately, the only program that can truly know--and the only one that should be tasked with knowing--what privileges are needed to perform an operation is the program performing that operation. (And note that major refactoring, such as splitting a program into a series of interoperating processes w/ discrete privileges sets, is usually not a realistic option. If it were then solutions like Capsicum would be more than adequate. Certainly new software should try to use this approach if it can.) At the end of the day, when it comes to security you can't really save vulnerable software from itself without touching that software. Attempting to build sandboxes outside that software doesn't work well in practice. Witness SELinux, which most people disable because the rules (invariably written by people other than the authors of the programs) are too brittle and prone to breaking functionality. But neither, of course, is it practical to rearchitect all our software. The reason why pledge and unveil and their default semantics of non-inheritance work so well is that they provide an optimal middle-ground. Each program concerns itself w/ minimizing its own privileges, and relies on programs it invokes to do the same. And w/ a good API, like pledge and unveil, in a shockingly short period of time those expectations (that a child program does know how to restrict its own permissions) can be substantially met w/ minimal effort. The typical patch to OpenBSD utilities included just several lines of code spread around various critical areas. For example, open or (if you can't open immediately) unveil any file paths passed on the command-line. Ditto for extraneous resources like /bin/gzip or /etc/magic. Then drop as many other privileges as you can as soon as you can, like network access. The appropriate way to do this is always highly dependent on the function and architecture of the program. Of course, if you're a leaf program then, yes, you want restrictions to be inherited by default in case some bug permits uncontrolled invocation of a utility. But in most of these cases this can be solved by, e.g., blocking exec. As a framework matures, sure, extensions can be added for the niche cases where you want to toggle inheritance and/or pre-specify restrictions as the invoker of another program. But these features should not be the emphasis, and they definitely shouldn't be provided in lieu of interfaces for non-inherited restrictions.
compsciphd 5y ago
re invoking other tools: I built this years ago (if i'd do it again, I'd implement it with LSM, but was coming from a lab with lots of stackable fs experience, so my thought process went there), used exec() to transition rule sets. https://www.usenix.net/legacy/events/lisa07/tech/full_papers/potter/potter.pdf https://www.usenix.net/legacy/events/lisa07/tech/full_papers...

chalst 5y ago

> FreeBSD has similar stuff and it is also super complicated and basically unused.. Are you talking about Capsicum? It's definitely not unused. Unloved, maybe. There was a Reddit thread where some people talked about the possibility of layering pledge/unveil on top of it. https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds_jails_basically_accomplish_the_same/ https://www.reddit.com/r/freebsd/comments/jldsm2/do_freebsds... Something along these lines has been done by Ryan Stone https://papers.freebsd.org/2020/bsdcan/stone-oblivious_sandboxing_capsicum_ebpf/ https://papers.freebsd.org/2020/bsdcan/stone-oblivious_sandb...

toast0 5y ago
Capsicum seems so useful, but some of the boundaries are so rigid. As far as I could tell, you can't capsicum anything like a TLS terminator or http proxy etc, because there's no way to allow opening new sockets after entering capabilities mode; you could have another process open up the sockets and pass the FD, but if I'm writing both the sandboxed process and the one that opens sockets, I'm not sure it makes enough difference. I ended up with jails instead, being stuck in a chroot with only a static executable, a config file, and a log file felt good enough to me.
- trasz 5y ago
  It’s rigid, because it implements a security architecture (capability-based security) instead of providing a mechanism to implement random restrictions.
  - chalst 5y ago
    Capability-based security can be done flexibly: look at EROS and E: http://www.erights.org/related.html http://www.erights.org/related.html
1MachineElf 5y ago
zie may be referring to the Mandatory Access Control implementation on FreeBSD[0], not Capsicum. [0] https://docs.freebsd.org/en/books/handbook/mac/ https://docs.freebsd.org/en/books/handbook/mac/