6 ms·

> they provide little to prevent unknown bugs bing exploited They provide plenty of mitigations (https://www.openbsd.org/innovations.html https://www.openbsd.o

> they provide little to prevent unknown bugs bing exploited They provide plenty of mitigations (https://www.openbsd.org/innovations.html https://www.openbsd.org/innovations.html). In fact OP's article is for preventing unknown bugs from being exploited.

PrimeMcFly 3y ago
They don't provide any mitigations of the sort I was clearly referencing. Specifically, for restricting malicious code or users that already has access to the system, exploiting insecure software that was not compiled with pledge support.
- saagarjha 3y ago
  What kind of mitigations would help here?
  - PrimeMcFly 3y ago
    SELinux/RSBAC/AppArmor/grsecurity and similar.
    - saagarjha 3y ago
      These largely require buy-in from applications just like pledge.
      - PrimeMcFly 3y ago
        They absolutely don't, that's the key difference. What makes you think otherwise?
        saagarjha 3y ago
        You can’t just stick sandboxing around arbitrary apps without them breaking.
        PrimeMcFly 3y ago
        The technologies I listed are not sandboxing, as that term refers to a different category of technology. And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.
        saagarjha 3y ago
        Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.
        PrimeMcFly 3y ago
        It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct. > The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly. That's why there are things like, for example, SELinux permissive mode, where you run the software as needed and observe the permissions it needs, and then grant it those permissions while denying everything else.
        saagarjha 3y ago
        I mean the typical term used for such things is “mandatory access control” but they always get used to implement a sandbox so that’s what I call them. Also, watching a program to see what it does is exactly the issue I’m talking about. You’re stuck with whatever behaviors you tested and everything else that you didn’t hit will fail (loudly if you’re lucky, silently if you’re not). There are platforms that do exactly what you’re talking about and believe me working on these rules is miserable. You’ll have reports on your desk like “the profiler doesn’t work anymore” (nobody tested this) or “on desktop controls don’t render anymore” (someone changed the implementation and it needs something you didn’t include in your rules). Again, this is when you control the stack, doing this for arbitrary programs is an order of magnitude harder.

PrimeMcFly 3y ago

They don't provide any mitigations of the sort I was clearly referencing. Specifically, for restricting malicious code or users that already has access to the system, exploiting insecure software that was not compiled with pledge support.

saagarjha 3y ago
What kind of mitigations would help here?
- PrimeMcFly 3y ago
  SELinux/RSBAC/AppArmor/grsecurity and similar.
  - saagarjha 3y ago
    These largely require buy-in from applications just like pledge.
    - PrimeMcFly 3y ago
      They absolutely don't, that's the key difference. What makes you think otherwise?
      - saagarjha 3y ago
        You can’t just stick sandboxing around arbitrary apps without them breaking.
        PrimeMcFly 3y ago
        The technologies I listed are not sandboxing, as that term refers to a different category of technology. And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.
        saagarjha 3y ago
        Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.
        PrimeMcFly 3y ago
        It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct. > The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly. That's why there are things like, for example, SELinux permissive mode, where you run the software as needed and observe the permissions it needs, and then grant it those permissions while denying everything else.
        saagarjha 3y ago
        I mean the typical term used for such things is “mandatory access control” but they always get used to implement a sandbox so that’s what I call them. Also, watching a program to see what it does is exactly the issue I’m talking about. You’re stuck with whatever behaviors you tested and everything else that you didn’t hit will fail (loudly if you’re lucky, silently if you’re not). There are platforms that do exactly what you’re talking about and believe me working on these rules is miserable. You’ll have reports on your desk like “the profiler doesn’t work anymore” (nobody tested this) or “on desktop controls don’t render anymore” (someone changed the implementation and it needs something you didn’t include in your rules). Again, this is when you control the stack, doing this for arbitrary programs is an order of magnitude harder.