4 ms·

> 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 t

> 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.
- Zurrrrr 4y ago
  > The same thing as any other framework. No. Not even close. You're missing the point. There is a fundamental difference which you are ignoring or blind to. With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework. This means with pledge, you can only limit to what the program needs, which may well be enough (and with something like Oracle it's almost guaranteed) for an attacker to escape whatever confines you think you have in place. That simply isn't true for a MAC framework where you can limit to a greater extent and with a lot more granularity. > Luckily, you can pledge and unveil from outside the process, as the code above does. That doesn't help even slightly and has no bearing on the point I made. > Yes, that's what you get with pledge and unveil. Jesus christ no you don't. Not even close. At this point it's abundantly clear you are not familiar with MAC frameworks at all, and you're just convinced that pledge and unveil are the same thing. That's willful ignorance and nothing more. > If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak. You haven't shown that pledge and unveil are as good at SELinux at locking down something like Oracle, you're just claiming it is with hand waiving. pledge and unveil simply don't offer what SELinux does, and you're just dismissing that and insisting they do. Ridiculous.
  - ori_b 4y ago
    > With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework. Go ahead, tell me a specific thing that I can't limit with pledge and unveil. Note that everything you mentioned when discussing Oracle could be done with them. I've provided code. You haven't even listed a threat model. You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides. (I certainly agree that it's more flexible, more complicated, and more difficult to configure -- but not that it's more secure). Again, there's example code sitting right there, which can be used for something like Oracle. Prove that there's an escape.
    - Zurrrrr 4y ago

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.

Zurrrrr 4y ago
> The same thing as any other framework. No. Not even close. You're missing the point. There is a fundamental difference which you are ignoring or blind to. With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework. This means with pledge, you can only limit to what the program needs, which may well be enough (and with something like Oracle it's almost guaranteed) for an attacker to escape whatever confines you think you have in place. That simply isn't true for a MAC framework where you can limit to a greater extent and with a lot more granularity. > Luckily, you can pledge and unveil from outside the process, as the code above does. That doesn't help even slightly and has no bearing on the point I made. > Yes, that's what you get with pledge and unveil. Jesus christ no you don't. Not even close. At this point it's abundantly clear you are not familiar with MAC frameworks at all, and you're just convinced that pledge and unveil are the same thing. That's willful ignorance and nothing more. > If you think otherwise -- I gave you a program that runs any arbitrary binary; please show a demo of a jailbreak. You haven't shown that pledge and unveil are as good at SELinux at locking down something like Oracle, you're just claiming it is with hand waiving. pledge and unveil simply don't offer what SELinux does, and you're just dismissing that and insisting they do. Ridiculous.
- ori_b 4y ago
  > With something like pledge, you can't limit anywhere near as much as what you can limit with a MAC framework. Go ahead, tell me a specific thing that I can't limit with pledge and unveil. Note that everything you mentioned when discussing Oracle could be done with them. I've provided code. You haven't even listed a threat model. You just yelled a bit about root escapes, and then when challenged to provide an example, yelled about Oracle. And then yelled a bit about how MAC provides more, without any specifics about which relevant 'more' it provides. (I certainly agree that it's more flexible, more complicated, and more difficult to configure -- but not that it's more secure). Again, there's example code sitting right there, which can be used for something like Oracle. Prove that there's an escape.
  - Zurrrrr 4y ago