4 ms·

> You put words in my mouth and seemed to be misconstruing my point. I'm just trying to put meat on the bones of your argument, which I thought was: "'secure b

> You put words in my mouth and seemed to be misconstruing my point. I'm just trying to put meat on the bones of your argument, which I thought was: "'secure by default' by OBSD basically just means everything disabled by default." Seems reasonable to infer that you meant if I enabled some stuff I'd have significantly more remote holes, which didn't seem true. You then said that wasn't your argument: > Generally for a server people are running some kind of services, and that's going to include third party software. Not always, but often, and that software is not audited by OBSD team. Even say adding a module to httpd may allow for remote compromise I think "an insecure PHP app" qualifies as third party software, 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? > like the people claiming if someone got root on SELinux they could just change the SELinux policies In fairness, this isn't unlike your claim that you can bit-twiddle raw devices in a chroot to find a filesystem ("If you have root, you have access to the files, period. Someone determined enough could search, read and write to the disk directly, bypassing the filesystem"). Well, there are differences: in a chroot you don't have access to the raw devices and OpenBSD's default securelevel already mounts them read-only besides. > My point was that OBSD, if it wants to be a security focused OS and taken seriously as such, should offer something along those lines. > Pretty sure SELinux (not Linux) has a better track record than OBSD for serious bugs, and none that have allowed full compromise unlike with OpenBSD. SELinux has a huge attack surface, and has had a lot of privilege escalation and code execution bugs [0]. I know it's kind of a polemic, but hard to not call it a rootkit at this point. I think OpenBSD deciding to not build something like it is a pretty good security choice. It's probably a good idea that root is just another user, but privesc means becoming any user, so in the wake of those vulns that design choice doesn't buy you very much. > As far as I'm concerned, the quality of my replies is proportional to the comments I am replying to. I get where you're coming from here--and I've definitely done it myself--but that's the kind of thing that lowers the quality of discussion here. You can't control what other people post, but you can control how you respond. [0]: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=selinux

Zurrrrr 4y ago
> 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

Zurrrrr 4y ago

> 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