6 ms·

That checklist is interesting. In what sense does OpenBSD have most of the base OS sandboxed? I'm kind of skeptical of that, but wondering if I missed something

That checklist is interesting. In what sense does OpenBSD have most of the base OS sandboxed? I'm kind of skeptical of that, but wondering if I missed something. What any BSD needs to have a merit to a claim to security, in 2024, is some form of MAC. As long as there is no way to take away from having an all powerful root user (and pledge and unveil ain't it), then they have a long ways to go.

loeg 2y ago
> In what sense does OpenBSD have most of the base OS sandboxed? They're talking about pledge. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- ruthmarx 2y ago
  I thought that might be the case. So not actually sandboxing at all.
  - yjftsjthsd-h 2y ago
    What does Sandboxing™ give you that pledge+unveil doesn't?
    - ruthmarx 2y ago
      > Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that. Something like linux namespaces or even capabilities would be a hell of a lot better though.
      - ori_b 2y ago
        Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors. An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't even their own configs.
        BSDobelix 2y ago
        Oh look who is here Ori!! How is gefs going and do we have in the next 9Front release?
        ruthmarx 2y ago
        > An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in. A good sandboxing solution should be robust and not require the cooperation of the programs that require sandboxing.
        0x457 2y ago
        Those are two different kinds of sandboxing. One protects application from itself - "here is what I use, if I try anything else, then it's a bug". Sandboxing you're talking about protects system from the application. You really need both. re: restrictiveness With external sandboxing, you need to restrict to a common denominator of all application states you see youself observing that application. Internal sandbox can adjust itself as it goes.
        ruthmarx 2y ago
        > Those are two different kinds of sandboxing. I'm arguing that only one example is sandboxing, the other is imposing limitations but doesn't meet the definition of sandboxing.

loeg 2y ago

> In what sense does OpenBSD have most of the base OS sandboxed? They're talking about pledge. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

ruthmarx 2y ago
I thought that might be the case. So not actually sandboxing at all.
- yjftsjthsd-h 2y ago
  What does Sandboxing™ give you that pledge+unveil doesn't?
  - ruthmarx 2y ago
    > Sandboxing™ Writing it like this is kind of funny, hoenstly, but not for the reasons you probably think. > give you that pledge+unveil doesn't? Not requiring the cooperation of developers to opt-in, for starters. You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that. Something like linux namespaces or even capabilities would be a hell of a lot better though.
    - ori_b 2y ago
      Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors. An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't even their own configs.
      - BSDobelix 2y ago
        Oh look who is here Ori!! How is gefs going and do we have in the next 9Front release?
      - ruthmarx 2y ago
        > An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in. A good sandboxing solution should be robust and not require the cooperation of the programs that require sandboxing.
        0x457 2y ago
        Those are two different kinds of sandboxing. One protects application from itself - "here is what I use, if I try anything else, then it's a bug". Sandboxing you're talking about protects system from the application. You really need both. re: restrictiveness With external sandboxing, you need to restrict to a common denominator of all application states you see youself observing that application. Internal sandbox can adjust itself as it goes.
        ruthmarx 2y ago
        > Those are two different kinds of sandboxing. I'm arguing that only one example is sandboxing, the other is imposing limitations but doesn't meet the definition of sandboxing.