4 ms·

Oracle, and third party software was the example I used from the start. SELinux absolutely can protect Oracle or any complex program. If you want t discuss thi

Oracle, and third party software was the example I used from the start. SELinux absolutely can protect Oracle or any complex program. If you want t discuss this further, illustrate how pledge can protect against a remote root exploit in Oracle as good or better than SELinux can.

ori_b 4y ago
Again, can you give an example of an jailbreak you're thinking of? So far, I don't even think you've given a clear explanation of your threat model. Once we have that, we can have a discussion about Oracle fits into it -- but until then, there's no substance. What operations would you use to break out of the above sandbox? Once you give me that, I'll happily discuss the details.
- Zurrrrr 4y ago
  Again, from the start, my scenario and example was third party software. Feel free to re-read the thread from the start if you want to confirm that. I'm not interested in retreading anything. I don't even want to continue discussing anything with you as it is, but I'm willing to see where this goes. Show how pledge can protect against a remote root compromise in oracle. I doubt it can, you've been insisting pledge is all OpenBSD needs to protect against such attacks. I'm not answering any more questions or taking any more detours. Stop being intellectually dishonest. Either admit that you don't know for sure that pledge can protect against a remote root compromise in complex third party software like oracle and simply think it can, or show how it can. If you can't do that, we're at an impasse and there won't be further discussion. Unless you post some kind of baiting comment I suppose, which wouldn't surprise me at this point.
  - ori_b 4y ago
    You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly. The program upthread will let you do that. It won't be as good as Oracle doing its own pledges, of course, because well pledged programs narrow down their pledge set as they run -- but if you have a binary that you can't modify, this is as good as you can do with any security framework. For example, Linux has landed on the same model as pledge when they added landlock, where a program is expected to landlock itself after opening the initial handles to resources.
    - Zurrrrr 4y ago
      > You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly. And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then? > It won't be as good as Oracle doing its own pledges, of course And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all. > but if you have a binary that you can't modify, this is as good as you can do with any security framework. This is where a MAC framework has a strength and advantage over pledge. With pledge/unveil and oracle, you likely won't be able to sufficiently restrict access to data or devices to prevent lateral movement and prevent further compromise, as complex programs like that require too much access to function correctly. With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what to permit or deny. Pledge and unveil simply can't compare. In some scenarios they may be sufficient, but in most, and certainly in most where an attacker has root, they are not.
      - ori_b 4y ago
        > And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then? The same thing as any other framework. You either grant it access, or you don't. The list of files just gets long. > And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all. Luckily, you can pledge and unveil from outside the process, as the code above does. Once more, that runs an arbitrary command under pledges and unveils. The thing lost is the ability reduction in access during the program lifetime, which is something that can only be done with the cooperation of the binary running; you don't have enough information to know when (for example) the code setting up the last network listener needed has been run without the help of the binary. You don't get that in most security frameworks anyways, so this is not a weakness in comparison to them. > With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what Yes, that's what you get with pledge and unveil. If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.

ori_b 4y ago

Again, can you give an example of an jailbreak you're thinking of? So far, I don't even think you've given a clear explanation of your threat model. Once we have that, we can have a discussion about Oracle fits into it -- but until then, there's no substance. What operations would you use to break out of the above sandbox? Once you give me that, I'll happily discuss the details.

Zurrrrr 4y ago
Again, from the start, my scenario and example was third party software. Feel free to re-read the thread from the start if you want to confirm that. I'm not interested in retreading anything. I don't even want to continue discussing anything with you as it is, but I'm willing to see where this goes. Show how pledge can protect against a remote root compromise in oracle. I doubt it can, you've been insisting pledge is all OpenBSD needs to protect against such attacks. I'm not answering any more questions or taking any more detours. Stop being intellectually dishonest. Either admit that you don't know for sure that pledge can protect against a remote root compromise in complex third party software like oracle and simply think it can, or show how it can. If you can't do that, we're at an impasse and there won't be further discussion. Unless you post some kind of baiting comment I suppose, which wouldn't surprise me at this point.
- ori_b 4y ago
  You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly. The program upthread will let you do that. It won't be as good as Oracle doing its own pledges, of course, because well pledged programs narrow down their pledge set as they run -- but if you have a binary that you can't modify, this is as good as you can do with any security framework. For example, Linux has landed on the same model as pledge when they added landlock, where a program is expected to landlock itself after opening the initial handles to resources.
  - Zurrrrr 4y ago
    > You exec oracle with an unveil that prevents a compromised oracle from touching any data that you didn't intend, and an exec pledge that removes the ability to open any raw devices other than the ones you handed to it directly. And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then? > It won't be as good as Oracle doing its own pledges, of course And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all. > but if you have a binary that you can't modify, this is as good as you can do with any security framework. This is where a MAC framework has a strength and advantage over pledge. With pledge/unveil and oracle, you likely won't be able to sufficiently restrict access to data or devices to prevent lateral movement and prevent further compromise, as complex programs like that require too much access to function correctly. With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what to permit or deny. Pledge and unveil simply can't compare. In some scenarios they may be sufficient, but in most, and certainly in most where an attacker has root, they are not.
    - ori_b 4y ago
      > And if it needs access to an awful lot of data across the file system or raw devices (which is not uncommon for complex proprietary commercial software), what then? The same thing as any other framework. You either grant it access, or you don't. The list of files just gets long. > And that's part of the issue, because you can't count on or only use software which is making pledges, and no commercial software will at all. Luckily, you can pledge and unveil from outside the process, as the code above does. Once more, that runs an arbitrary command under pledges and unveils. The thing lost is the ability reduction in access during the program lifetime, which is something that can only be done with the cooperation of the binary running; you don't have enough information to know when (for example) the code setting up the last network listener needed has been run without the help of the binary. You don't get that in most security frameworks anyways, so this is not a weakness in comparison to them. > With a MAC framework you can. Now the binary has no access to certain parts of the filesystem in a way that is much more secure than a chroot, only has access to syscalls it needs (on par with pledge here), can't execute other binaries, can't make library calls, can't access devices (e.g. tty, network), can't switch user context, can't do anything as root even if root were obtained, can't write to ANY files only append, can't delete ANY files, etc etc etc. You have complete granular control over many more aspects of what Yes, that's what you get with pledge and unveil. If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak.