8 ms·

It seems you didn't properly read my comment. I'm not talking about GETTING root, I'm talking about in the situation where an attacker already HAS root.

yjftsjthsd-h 4y ago
You did, actually; you said that OpenBSD just "really really really hopes" that an attacker won't get root, and I pointed out that that was nonsense and that they are in fact taking measures to ensure it. Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process.
- Zurrrrr 4y ago
  Sigh. No, I didn't. Saying OpenBSD 'really really really hopes' an attacker doesn't get root is still 100% correct. They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to. > Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process. Which is where things like SELinux come in, which is my whole point.....
  - yjftsjthsd-h 4y ago
    > They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to. They're absolutely dealing with that situation as well. So let's say for instance that the default OpenBSD httpd turns out to have some bug that allows an attacker to execute any arbitrary code of their choosing on the server. That's a problem, but it's hardly the end of the world. First, the server is using pledge+unveil, so it can't actually do all that much other than serving web pages. Second, even if the attacker can work within those restrictions, they're running as a completely unprivileged user, because OpenBSD is actually a great fan of defense in depth. > Which is where things like SELinux come in, which is my whole point..... If we're assuming an attacker can run things as root, then obviously we have to assume that they can run things in an unconfined context as well, at which point you've just basically added a second word for root and nothing helps.
    - anthk 4y ago
      Also, pledge would SIGABRT that's process under a milisecond upon trying a non-allowed syscall. So, as I said, good luck trying to call something outside pledge. Being root? You wish if you can even run something alonside the process. Because even the subprocesses from a pledged process are pledged too.
      - Zurrrrr 4y ago
        If someone has remote root pledge is basically irrelevant.
        anthk 4y ago
        Getting remote root is not easy as you'd think under OpenBSD.
        Zurrrrr 4y ago
        Jesus christ, once again, the point is it doesn't matter. There is nothing in place if someone does. Good security is preparing for different possibilities, not just hoping one never happens because it seems unlikely. You're just proving what I said above 100% correct, that the OBSD approach is to just really hope that no one ever gets remote root. Tell you what, getting root on a properly configured MAC system is 100% impossible, so I'll choose that over a system where the developers just really really hope something bad won't happen every day of the week.
        ori_b 4y ago
        Pledge means YOU HAVE NO SYSCALLS. There is no amount of root magic that can allow the code you've exploited to do IO.
        Zurrrrr 4y ago
        I honestly can't even imagine putting all my faith in pledge and chroot like you do. It genuinely boggles my mind that you think this is a good approach.
ori_b 4y ago
"When you've already been compromised, OpenBSD doesn't prevent you from being compromised"
- Zurrrrr 4y ago
  Well yeah, kind of. If you consider there are levels of compromise at least. SELinux and similar frameworks do prevent further compromise. That's the point.
  - ori_b 4y ago
    By your logic elsewhere -- if you're root, you can just remove the selinux policies.
    - Zurrrrr 4y ago
      You're really just showing you have no clue what you are talking about lol. That seems to be true for most of the people in this thread defending OpenBSD, as you're not the first to make the point. The reason it's wrong, the reason it's clear that you have no clue what you are talking about, is it's a basic design decision that it is not the root user that configures or removes policies. Root has no ability to do what you describe, and under SELinux is just another user. But hey, keep spouting nonsense because your feelings are hurt because you have some weird attachment to an obscure OS.
      - ori_b 4y ago
        If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user? Possibly by using the same exploit you'd use to get root, or possibly by using the permissions root has?
        Zurrrrr 4y ago
        I'm not being smug or insulting when I ask this, but are you familiar with SELinux at all, or have you administered any systems? > If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user? SELinux maintains it's own set of users that map to unix user. SELinux users have their own roles and capabilities that are very granular. It's frequently configured to make root 'just another user' as much as possible, and remove any access root doesn't need. So if you 'get root' on a properly configured SELinux system, you don't actually 'have root', you just have a user with a user id of 0 but no real access. You can switch to whatever user administers SELinux policies, but you will only be switching in the unix sense, not the SELinux sense, so you won't actually be able to do anything. To do what you are suggesting would require a kernel exploit, but even if you get root you won't have any access to run it. What you suggest simply is not possible barring very specific vulnerabilities being found, which afaik, have not been.

yjftsjthsd-h 4y ago

You did, actually; you said that OpenBSD just "really really really hopes" that an attacker won't get root, and I pointed out that that was nonsense and that they are in fact taking measures to ensure it. Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process.

Zurrrrr 4y ago
Sigh. No, I didn't. Saying OpenBSD 'really really really hopes' an attacker doesn't get root is still 100% correct. They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to. > Besides, by that logic, your systems are totally insecure because you're just really really really hoping the attacker doesn't get an unconfined process. Which is where things like SELinux come in, which is my whole point.....
- yjftsjthsd-h 4y ago
  > They are still prioritizing removing bugs ahead of time instead of providing stronger tools to prepare for a scenario where someone does exploit a bug they didn't get to. They're absolutely dealing with that situation as well. So let's say for instance that the default OpenBSD httpd turns out to have some bug that allows an attacker to execute any arbitrary code of their choosing on the server. That's a problem, but it's hardly the end of the world. First, the server is using pledge+unveil, so it can't actually do all that much other than serving web pages. Second, even if the attacker can work within those restrictions, they're running as a completely unprivileged user, because OpenBSD is actually a great fan of defense in depth. > Which is where things like SELinux come in, which is my whole point..... If we're assuming an attacker can run things as root, then obviously we have to assume that they can run things in an unconfined context as well, at which point you've just basically added a second word for root and nothing helps.
  - anthk 4y ago
    Also, pledge would SIGABRT that's process under a milisecond upon trying a non-allowed syscall. So, as I said, good luck trying to call something outside pledge. Being root? You wish if you can even run something alonside the process. Because even the subprocesses from a pledged process are pledged too.
    - Zurrrrr 4y ago
      If someone has remote root pledge is basically irrelevant.
      - anthk 4y ago
        Getting remote root is not easy as you'd think under OpenBSD.
        Zurrrrr 4y ago
        Jesus christ, once again, the point is it doesn't matter. There is nothing in place if someone does. Good security is preparing for different possibilities, not just hoping one never happens because it seems unlikely. You're just proving what I said above 100% correct, that the OBSD approach is to just really hope that no one ever gets remote root. Tell you what, getting root on a properly configured MAC system is 100% impossible, so I'll choose that over a system where the developers just really really hope something bad won't happen every day of the week.
        ori_b 4y ago
        Pledge means YOU HAVE NO SYSCALLS. There is no amount of root magic that can allow the code you've exploited to do IO.
        Zurrrrr 4y ago
        I honestly can't even imagine putting all my faith in pledge and chroot like you do. It genuinely boggles my mind that you think this is a good approach.

ori_b 4y ago

"When you've already been compromised, OpenBSD doesn't prevent you from being compromised"

Zurrrrr 4y ago
Well yeah, kind of. If you consider there are levels of compromise at least. SELinux and similar frameworks do prevent further compromise. That's the point.
- ori_b 4y ago
  By your logic elsewhere -- if you're root, you can just remove the selinux policies.
  - Zurrrrr 4y ago
    You're really just showing you have no clue what you are talking about lol. That seems to be true for most of the people in this thread defending OpenBSD, as you're not the first to make the point. The reason it's wrong, the reason it's clear that you have no clue what you are talking about, is it's a basic design decision that it is not the root user that configures or removes policies. Root has no ability to do what you describe, and under SELinux is just another user. But hey, keep spouting nonsense because your feelings are hurt because you have some weird attachment to an obscure OS.
    - ori_b 4y ago
      If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user? Possibly by using the same exploit you'd use to get root, or possibly by using the permissions root has?
      - Zurrrrr 4y ago
        I'm not being smug or insulting when I ask this, but are you familiar with SELinux at all, or have you administered any systems? > If you believe that there's a way to become root, why don't you believe there's a way to become some other non-root user? SELinux maintains it's own set of users that map to unix user. SELinux users have their own roles and capabilities that are very granular. It's frequently configured to make root 'just another user' as much as possible, and remove any access root doesn't need. So if you 'get root' on a properly configured SELinux system, you don't actually 'have root', you just have a user with a user id of 0 but no real access. You can switch to whatever user administers SELinux policies, but you will only be switching in the unix sense, not the SELinux sense, so you won't actually be able to do anything. To do what you are suggesting would require a kernel exploit, but even if you get root you won't have any access to run it. What you suggest simply is not possible barring very specific vulnerabilities being found, which afaik, have not been.