4 ms·

> I'm just trying to put meat on the bones of your argument, If you were uncertain about something, why not just ask? > I think "an insecure PHP app" qualifie

> I'm just trying to put meat on the bones of your argument, If you were uncertain about something, why not just ask? > I think "an insecure PHP app" qualifies as third party software, mod_php would be, not the php app itself. > and it sounds like unveil/pledge/chroot mitigates the scenario you're describing. Can you explain why that's a bad example, and do you have a better one? It's a bad example because it's not really a separate app so much as it is a slight extension to httpd that might introduce some insecurities. A better example would be running an actual app...a database for example, maybe an irc server, a jabba server, anything that listens on it's own port and accepts network connections. unveil/pledge/chroot won't mitigate any scenario where an attacker has remote root to satisfaction. > In fairness, this isn't unlike your claim that you can bit-twiddle raw devices in a chroot to find a filesystem It's radically different. You would have to leverage root to gain access to another user that isn't managed by the system, and where you have no real access despite being root. There is no pathway to do what you suggest. At all. > in a chroot you don't have access to the raw devices We're not going to agree on this at all lol. chroot as protection is just fundamentally weaker and it should ONLY be part of defense in depth, while you and other people seem to be happy with it as almost a final solution. chroots can be escaped, the openbsd team even warn of this on the manpage for their own chroot. > SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs Sure, but none of which can be utilized in the way you suggest is possible. Got an example that shows otherwise? > but hard to not call it a rootkit at this point. Well that's ridiculous. > I think OpenBSD deciding to not build something like it is a pretty good security choice. And that's flat out wrong. You're not keen on selinux because of the complexity, but not all implementations have to be that complex. Look at things like rsbac and apparmor. > so in the wake of those vulns that design choice doesn't buy you very much. This just doesn't make sense, period. On an SELinux system, you won't be able to simply switch to the policy administrator and give yourself whatever access you want. That shows IMO a fundamental misunderstanding of how SELinux works. > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux So which of these allow for a restricted root to switch a user with a role that can administer SELinux policies, and how would the attacker find out which user that is?

camgunz 4y ago
>> I think "an insecure PHP app" qualifies as third party software, > mod_php would be, not the php app itself. I don't see a difference here. Why does it matter if mod_php sends all your SSH keys or cool_app.php does? What would SELinux prevent here that pledge/chroot wouldn't? > A better example would be running an actual app...a database for example, maybe an irc server OpenBSD's ngircd has a pretty good track record [0]. The out-of-bounds read in CVE-2020-14148 isn't great, but chroot/pledge/not running as root mitigates a lot of badness. Can you explain what SELinux would prevent here that OpenBSD's security features don't? It sounds like on either system you'd be limited either to whatever the confined process can do, or to whatever the chroot/pledge/user can do. Aren't these just different ways of specifying capabilities? What capabilities would SELinux restrict that OpenBSD wouldn't let you? BTW this is an opportunity to sell me on SELinux--I am genuinely curious here. I mostly think the RBAC in UNIXish systems doesn't do the trick anymore, because appsec is so much more complicated. > unveil/pledge/chroot won't mitigate any scenario where an attacker has remote root to satisfaction. How would you get remote root from CVE-2020-14148? Or is there another example you're working off of? It's empirically pretty hard to get remote root on OpenBSD, and you've yet to find a module or an internet-facing app that would have let you do it. Your "remote root" claim is so far a claim without evidence. > There is no pathway to do what you suggest. At all. I agree! You're the one saying you can get access to raw devices and do whatever you want with them regardless of security features. I'm saying if this is true it applies to both your claims about OpenBSD's security features and SELinux. But I think this is another unbacked claim from you. >> in a chroot you don't have access to the raw devices > We're not going to agree on this at all lol. Well, another way of saying this is that you've yet to persuade anyone that you can jailbreak OpenBSD's chroot. You continue to make this claim that it's "a toy" and such, but despite that it seems like it's doing the job. If you want to convince people that SELinux does what chroot doesn't, you gotta give an example, which you've yet to do. >> SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs > Sure, but none of which can be utilized in the way you suggest is possible. Got an example that shows otherwise? Sure, the 1st privesc bug [1] has a pretty detailed write-up on Project Zero's mailing list. Privesc doesn't just mean getting UID 0, it means getting any UID you want--or in this case, any SELinux context you want. Doesn't this totally circumvent SELinux? >> so in the wake of those vulns that design choice doesn't buy you very much. > This just doesn't make sense, period. On an SELinux system, you won't be able to simply switch to the policy administrator and give yourself whatever access you want. I'm reading [2], where you do `usermod -Z <selinux user> <linux user>` as root to map Linux users to SELinux users and [3] where you do `semanage login -m -s <selinux user> <linux user>`. How does SELinux stop me from doing that? I assume if I'm mapped to secadm_r I can do whatever I want here, so how would SELinux prevent me from privescing to a user with that mapping and running these commands? > Look at things like rsbac and apparmor. The rsbac patch for 6.1.15 is > 120KLOC [4]. That's hefty to me. [0]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ngircd https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ngircd [1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=2229 https://bugs.chromium.org/p/project-zero/issues/detail?id=22... [2]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux#confining-an-administrator-by-mapping-to-sysadm_u_managing-confined-and-unconfined-users https://access.redhat.com/documentation/en-us/red_hat_enterp... [3]: https://rhel7stig.readthedocs.io/en/latest/medium.html#v-71971-the-operating-system-must-prevent-non-privileged-users-from-executing-privileged-functions-to-include-disabling-circumventing-or-altering-implemented-security-safeguards-countermeasures-rhel-07-020020 https://rhel7stig.readthedocs.io/en/latest/medium.html#v-719... [4]: https://download.rsbac.org/latestdiff/6.1/ https://download.rsbac.org/latestdiff/6.1/

camgunz 4y ago

>> I think "an insecure PHP app" qualifies as third party software, > mod_php would be, not the php app itself. I don't see a difference here. Why does it matter if mod_php sends all your SSH keys or cool_app.php does? What would SELinux prevent here that pledge/chroot wouldn't? > A better example would be running an actual app...a database for example, maybe an irc server OpenBSD's ngircd has a pretty good track record [0]. The out-of-bounds read in CVE-2020-14148 isn't great, but chroot/pledge/not running as root mitigates a lot of badness. Can you explain what SELinux would prevent here that OpenBSD's security features don't? It sounds like on either system you'd be limited either to whatever the confined process can do, or to whatever the chroot/pledge/user can do. Aren't these just different ways of specifying capabilities? What capabilities would SELinux restrict that OpenBSD wouldn't let you? BTW this is an opportunity to sell me on SELinux--I am genuinely curious here. I mostly think the RBAC in UNIXish systems doesn't do the trick anymore, because appsec is so much more complicated. > unveil/pledge/chroot won't mitigate any scenario where an attacker has remote root to satisfaction. How would you get remote root from CVE-2020-14148? Or is there another example you're working off of? It's empirically pretty hard to get remote root on OpenBSD, and you've yet to find a module or an internet-facing app that would have let you do it. Your "remote root" claim is so far a claim without evidence. > There is no pathway to do what you suggest. At all. I agree! You're the one saying you can get access to raw devices and do whatever you want with them regardless of security features. I'm saying if this is true it applies to both your claims about OpenBSD's security features and SELinux. But I think this is another unbacked claim from you. >> in a chroot you don't have access to the raw devices > We're not going to agree on this at all lol. Well, another way of saying this is that you've yet to persuade anyone that you can jailbreak OpenBSD's chroot. You continue to make this claim that it's "a toy" and such, but despite that it seems like it's doing the job. If you want to convince people that SELinux does what chroot doesn't, you gotta give an example, which you've yet to do. >> SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs > Sure, but none of which can be utilized in the way you suggest is possible. Got an example that shows otherwise? Sure, the 1st privesc bug [1] has a pretty detailed write-up on Project Zero's mailing list. Privesc doesn't just mean getting UID 0, it means getting any UID you want--or in this case, any SELinux context you want. Doesn't this totally circumvent SELinux? >> so in the wake of those vulns that design choice doesn't buy you very much. > This just doesn't make sense, period. On an SELinux system, you won't be able to simply switch to the policy administrator and give yourself whatever access you want. I'm reading [2], where you do `usermod -Z <selinux user> <linux user>` as root to map Linux users to SELinux users and [3] where you do `semanage login -m -s <selinux user> <linux user>`. How does SELinux stop me from doing that? I assume if I'm mapped to secadm_r I can do whatever I want here, so how would SELinux prevent me from privescing to a user with that mapping and running these commands? > Look at things like rsbac and apparmor. The rsbac patch for 6.1.15 is > 120KLOC [4]. That's hefty to me. [0]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ngircd https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ngircd [1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=2229 https://bugs.chromium.org/p/project-zero/issues/detail?id=22... [2]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux#confining-an-administrator-by-mapping-to-sysadm_u_managing-confined-and-unconfined-users https://access.redhat.com/documentation/en-us/red_hat_enterp... [3]: https://rhel7stig.readthedocs.io/en/latest/medium.html#v-71971-the-operating-system-must-prevent-non-privileged-users-from-executing-privileged-functions-to-include-disabling-circumventing-or-altering-implemented-security-safeguards-countermeasures-rhel-07-020020 https://rhel7stig.readthedocs.io/en/latest/medium.html#v-719... [4]: https://download.rsbac.org/latestdiff/6.1/ https://download.rsbac.org/latestdiff/6.1/