5 ms·

I was not familiar with these syscalls. Are they primarily in a “if you build it they will come” stage right now? Or is there an upswing of usage in the BSD wor

I was not familiar with these syscalls. Are they primarily in a “if you build it they will come” stage right now? Or is there an upswing of usage in the BSD world? Does the Linux kernel have any analog to pledge and unveil?

moonchild 5y ago
> BSD world Pledge/unveil are openbsd-specific. Freebsd has capsicum which, like seccomp (mentioned else-thread) is much more complex and flexible. Pledge/unveil are manifestly more successful, being used pervasively (though not really by programs which do not primarily target openbsd). Seccomp and capsicum are barely used at all (likely due to their higher complexity), and capsicum usage was even removed from a few freebsd utilities. At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec?
- foxfluff 5y ago
  > At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec? The validity of that criticism is so-so. It's a common complaint from people who are trying to build an externally imposed sandbox that dictates what a program can do. But that's not what pledge and unveil are. They're more of an internally imposed set of constraints: the program just announces what it's going to do. After that, if it breaks the contract (due to a bug or malicious intervention), the system has license to kill it. The program knows what it is going to do, so it can write the contract for itself. But it doesn't know what some other program is going to do, so it doesn't make sense for these restrictions to persist after exec. The program-to-be-exec'd should have its own pledges. In reality it's even more complicated than that: programs often need to perform some "privileged" operations before they are ready to put on their straight jacket. It'd be very hard for program A to say that program B starts with privileges X, Y, Z, and then after instruction Q drops Y and Z. And program B might require more privileges than what A had when it called exec, so again it's just not going to work for this at all. If A's privileges were to persist, then it would have to have some way to elevate them or it'd never drop them in the first place. Both seem like a bad deal. It's just a completely different mechanism, but people think sandbox sandbox sandbox and if that's all one can think of, pledge and unveil might seem like a terrible tool for that. They're not a tool for sandboxing untrusted programs.
  - ori_b 5y ago
    It's also worth noting that you can pledge for an execed process using the second argument to pledge. This is for when you know what the child is expected to do on your behalf.
- toast0 5y ago
  > Freebsd has capsicum which, like seccomp (mentioned else-thread) is much more complex and flexible. Capsicum may be more flexible in some ways, but it's also less flexible in others. After you a process entera capsicum mode, it can't open new sockets, except by accepting on an existing listen socket or by receiving them on a unix socket, sent by a cooperating non-capsicum process. This means you can't capsicum a TLS proxy like hitch, which would be a great thing to capsicum since the operation is pretty simple and OpenSSL is scary.
  - trasz 5y ago
    No true, of course you can do that. Not being able to open files or sockets only means you need a small separate process to do that for you and then send you the file descriptors.
    - toast0 5y ago
      I said you could get them from a cooperating uncapsicumed process. But, it's not simple, and what are you going to write that loophole process in, and why does it get access to the filesystem if it only needed sockets, etc. Capsicum is simply not flexible in this way. Maybe if there was a way to open a new socket with a capability you setup earlier, that would be flexible enough.
      - trasz 5y ago
        It is pretty simple - implementing that for irssi(1) took a dozen or two lines of C, IIRC. Sure, it could be simpler, and hopefully libcasper(3) will make it happen, but it's not much of a difference.
- the8472 5y ago
  A major limitation of seccomp is that you can't turn off inheritance. With pledge inheritance is opt-in. This has major consequences because it makes it possible for a process to secure itself without affecting its ability to spawn child processes. You could apply seccomp in-process or use a spawn-helper before securing it. But more realistically it means that one applies an external seccomp profile to a group of processes (e.g. a container) that contains the union of all needed syscalls. So while seccomp is more flexible in some sense (being able to run BPF filters on every syscall) its architecture leads to it being applied in a less flexible way.
- xnormal 5y ago
  > Pledge/unveil are manifestly more successful, being used pervasively (though not really by programs which do not primarily target openbsd). Because of their simplicity, they are easily added as a patch to a ported application. There are probably more ports using them than programs that target openbsd.
- protomyth 5y ago
  It really doesn't make much sense to compare pledge/unveil to seccomp and capsicum or any other sandboxing solution. Pledge and Unveil are really part of the program's specification. They are much closer in practice to asserts, pre-conditions, or contracts depending on the programming language you have used. They basically make sure that the program you are writing doesn't do anything stupid with bad inputs from the outside world. Its part of the development process, and not very hard to add to an existing program.
dbt00 5y ago
they only exist on OpenBSD. They're used a lot for default OpenBSD binaries, but they are mostly hopeless for openbsd developers/porters to try to apply to portable software after the fact if the upstream devs aren't supporting that work. (There are other mechanisms like containers or freebsd' jail that try to accomplish the same thing, but those tend to be "lots of functionality inside the sandbox" solutions, whereas openbsd is mostly aiming for "allow nothing besides the minimum in the sandbox". (edited for clarity, thanks for the nudge ghoward).
- ghoward 5y ago
  I upvoted, but I wanted to correct a small thing. > ...they are mostly hopeless to try to apply to portable software after the fact if the devs aren't constantly testing with it. They don't have to be hopeless. They were pretty easy ([1], [2]) to add to my bc. [1]: https://git.yzena.com/gavin/bc/commit/3e8cd345de9d5b65ac7c339b98a67b9fc3d87d9f https://git.yzena.com/gavin/bc/commit/3e8cd345de9d5b65ac7c33... [2]: https://git.yzena.com/gavin/bc/commit/b6c65bb44c910c054bedfaab40a4b9283345e080 https://git.yzena.com/gavin/bc/commit/b6c65bb44c910c054bedfa...
  - dbt00 5y ago
    Yes. That's awesome! I was referring to the OpenBSD devs trying to hack pledges into other people's software by trying to guess what capabilities it needs while porting. That's not a good thing to try to do -- see also all the various attempts at guessing seccomp profiles in the Linux world, which has the same problem.
    - ben_bai 5y ago
      Has been done to some 3rd party applications. Notably Chromium is pledged an unveiled, Firefox (unveil), pdf readers, compression tools, mail clients, ... grep the ports tree for pledge patches.
    - ghoward 5y ago
      I see what you mean now, and I think you are completely correct in that!
robmusial 5y ago
seccomp in linux is _roughly_ similar to pledge. they aim to accomplish the same goals but pledge is more straightforward. think of it like sudo vs doas.
- Godel_unicode 5y ago
  Seccomp profiles are typically applied externally to a process in my experience though. I think this is more analogous to using capset() to remove capabilities in highly permissioned processes. For instance dnsmasq makes use of this ability to be minimally permissioned.
masklinn 5y ago
> I was not familiar with these syscalls. Are they primarily in a “if you build it they will come” stage right now? It’s an openbsd feature they built for themselves and deployed throughout the base system.
chousuke 5y ago
To my understanding, you can use existing Linux kernel facilities like seccomp to build equivalents for pledge and unveil. The latter are less flexible but also easier to use, which is a point in their favour; ease of use matters for security.
ingve 5y ago
They are also available (and used) in SerenityOS: https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
baq 5y ago
looks like unveil() has an rough analog in Linux 5.13: https://landlock.io/ https://landlock.io/, there was even a HN discussion which I missed: https://news.ycombinator.com/item?id=27215563 https://news.ycombinator.com/item?id=27215563
- rbanffy 5y ago
  Would be useful to have a unified API…
  - oneplane 5y ago
    Indeed, but on the other hand, almost all of the projects mentioned in the comments here are of the 'for this project, we do it this way' type of implementation meaning that in their local use case their way is the unified API. That is both the benefit and the downside of non-commercial projects: you get to do whatever you want.
    - rbanffy 5y ago
      True. It may be worth postponing a unified API when the semantics solidify. I really like the pledge/unveil semantics, but it's not a consensus.

moonchild 5y ago

> BSD world Pledge/unveil are openbsd-specific. Freebsd has capsicum which, like seccomp (mentioned else-thread) is much more complex and flexible. Pledge/unveil are manifestly more successful, being used pervasively (though not really by programs which do not primarily target openbsd). Seccomp and capsicum are barely used at all (likely due to their higher complexity), and capsicum usage was even removed from a few freebsd utilities. At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec?

foxfluff 5y ago
> At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec? The validity of that criticism is so-so. It's a common complaint from people who are trying to build an externally imposed sandbox that dictates what a program can do. But that's not what pledge and unveil are. They're more of an internally imposed set of constraints: the program just announces what it's going to do. After that, if it breaks the contract (due to a bug or malicious intervention), the system has license to kill it. The program knows what it is going to do, so it can write the contract for itself. But it doesn't know what some other program is going to do, so it doesn't make sense for these restrictions to persist after exec. The program-to-be-exec'd should have its own pledges. In reality it's even more complicated than that: programs often need to perform some "privileged" operations before they are ready to put on their straight jacket. It'd be very hard for program A to say that program B starts with privileges X, Y, Z, and then after instruction Q drops Y and Z. And program B might require more privileges than what A had when it called exec, so again it's just not going to work for this at all. If A's privileges were to persist, then it would have to have some way to elevate them or it'd never drop them in the first place. Both seem like a bad deal. It's just a completely different mechanism, but people think sandbox sandbox sandbox and if that's all one can think of, pledge and unveil might seem like a terrible tool for that. They're not a tool for sandboxing untrusted programs.
- ori_b 5y ago
  It's also worth noting that you can pledge for an execed process using the second argument to pledge. This is for when you know what the child is expected to do on your behalf.
toast0 5y ago
> Freebsd has capsicum which, like seccomp (mentioned else-thread) is much more complex and flexible. Capsicum may be more flexible in some ways, but it's also less flexible in others. After you a process entera capsicum mode, it can't open new sockets, except by accepting on an existing listen socket or by receiving them on a unix socket, sent by a cooperating non-capsicum process. This means you can't capsicum a TLS proxy like hitch, which would be a great thing to capsicum since the operation is pretty simple and OpenSSL is scary.
- trasz 5y ago
  No true, of course you can do that. Not being able to open files or sockets only means you need a small separate process to do that for you and then send you the file descriptors.
  - toast0 5y ago
    I said you could get them from a cooperating uncapsicumed process. But, it's not simple, and what are you going to write that loophole process in, and why does it get access to the filesystem if it only needed sockets, etc. Capsicum is simply not flexible in this way. Maybe if there was a way to open a new socket with a capability you setup earlier, that would be flexible enough.
    - trasz 5y ago
      It is pretty simple - implementing that for irssi(1) took a dozen or two lines of C, IIRC. Sure, it could be simpler, and hopefully libcasper(3) will make it happen, but it's not much of a difference.
the8472 5y ago
A major limitation of seccomp is that you can't turn off inheritance. With pledge inheritance is opt-in. This has major consequences because it makes it possible for a process to secure itself without affecting its ability to spawn child processes. You could apply seccomp in-process or use a spawn-helper before securing it. But more realistically it means that one applies an external seccomp profile to a group of processes (e.g. a container) that contains the union of all needed syscalls. So while seccomp is more flexible in some sense (being able to run BPF filters on every syscall) its architecture leads to it being applied in a less flexible way.
xnormal 5y ago
> Pledge/unveil are manifestly more successful, being used pervasively (though not really by programs which do not primarily target openbsd). Because of their simplicity, they are easily added as a patch to a ported application. There are probably more ports using them than programs that target openbsd.
protomyth 5y ago
It really doesn't make much sense to compare pledge/unveil to seccomp and capsicum or any other sandboxing solution. Pledge and Unveil are really part of the program's specification. They are much closer in practice to asserts, pre-conditions, or contracts depending on the programming language you have used. They basically make sure that the program you are writing doesn't do anything stupid with bad inputs from the outside world. Its part of the development process, and not very hard to add to an existing program.

dbt00 5y ago

they only exist on OpenBSD. They're used a lot for default OpenBSD binaries, but they are mostly hopeless for openbsd developers/porters to try to apply to portable software after the fact if the upstream devs aren't supporting that work. (There are other mechanisms like containers or freebsd' jail that try to accomplish the same thing, but those tend to be "lots of functionality inside the sandbox" solutions, whereas openbsd is mostly aiming for "allow nothing besides the minimum in the sandbox". (edited for clarity, thanks for the nudge ghoward).

ghoward 5y ago
I upvoted, but I wanted to correct a small thing. > ...they are mostly hopeless to try to apply to portable software after the fact if the devs aren't constantly testing with it. They don't have to be hopeless. They were pretty easy ([1], [2]) to add to my bc. [1]: https://git.yzena.com/gavin/bc/commit/3e8cd345de9d5b65ac7c339b98a67b9fc3d87d9f https://git.yzena.com/gavin/bc/commit/3e8cd345de9d5b65ac7c33... [2]: https://git.yzena.com/gavin/bc/commit/b6c65bb44c910c054bedfaab40a4b9283345e080 https://git.yzena.com/gavin/bc/commit/b6c65bb44c910c054bedfa...
- dbt00 5y ago
  Yes. That's awesome! I was referring to the OpenBSD devs trying to hack pledges into other people's software by trying to guess what capabilities it needs while porting. That's not a good thing to try to do -- see also all the various attempts at guessing seccomp profiles in the Linux world, which has the same problem.
  - ben_bai 5y ago
    Has been done to some 3rd party applications. Notably Chromium is pledged an unveiled, Firefox (unveil), pdf readers, compression tools, mail clients, ... grep the ports tree for pledge patches.
  - ghoward 5y ago
    I see what you mean now, and I think you are completely correct in that!

robmusial 5y ago

seccomp in linux is _roughly_ similar to pledge. they aim to accomplish the same goals but pledge is more straightforward. think of it like sudo vs doas.

Godel_unicode 5y ago
Seccomp profiles are typically applied externally to a process in my experience though. I think this is more analogous to using capset() to remove capabilities in highly permissioned processes. For instance dnsmasq makes use of this ability to be minimally permissioned.

masklinn 5y ago

> I was not familiar with these syscalls. Are they primarily in a “if you build it they will come” stage right now? It’s an openbsd feature they built for themselves and deployed throughout the base system.

chousuke 5y ago

To my understanding, you can use existing Linux kernel facilities like seccomp to build equivalents for pledge and unveil. The latter are less flexible but also easier to use, which is a point in their favour; ease of use matters for security.

ingve 5y ago

They are also available (and used) in SerenityOS: https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...

baq 5y ago

looks like unveil() has an rough analog in Linux 5.13: https://landlock.io/ https://landlock.io/, there was even a HN discussion which I missed: https://news.ycombinator.com/item?id=27215563 https://news.ycombinator.com/item?id=27215563

rbanffy 5y ago
Would be useful to have a unified API…
- oneplane 5y ago
  Indeed, but on the other hand, almost all of the projects mentioned in the comments here are of the 'for this project, we do it this way' type of implementation meaning that in their local use case their way is the unified API. That is both the benefit and the downside of non-commercial projects: you get to do whatever you want.
  - rbanffy 5y ago
    True. It may be worth postponing a unified API when the semantics solidify. I really like the pledge/unveil semantics, but it's not a consensus.