Disk encryption wasn't even part of the default install flow before. You had to go out of your way to find documentation, understand how to run it, find some more documentation, get "RTFM" replies on their IRC channel.
Doesn't seem very secure by default to me.
Look, I was just trying OpenBSD with an open mind, and I met people who were unhelpful.
Even in the street if I asked someone for the time and he said "get a watch", it would be rude.
I understand that they don't want to help. But do they need to be rude about it?
Can't hack anything if nothing is running, right? Only issue is it's not that useable either.
- OpenSMTPd: 2 remote holes in 10 years
- OpenSSH: 1 remote hole in 10 years
- httpd: No remote vulns
- relayd: No remote vulns
What are you looking at that makes you confident that if OpenBSD ran these by default (which I think is a bad idea in general) they'd have a significantly worse security history?
My point is that:
a) 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
and
b)
That the tools OpenBSD provides for dealing with an attacker who has managed to gain remote access are insufficient compared to what is available, and especially insufficient for an OS that claims to be focused on security.
Oh so you're saying that things like ASLR, chrooting, and safe programming practices aren't useful in things like httpd, because you might run an insecure PHP app, and the only thing that helps you then is something like SELinux?
I think that's pretty wrong. Running services in a chroot with pledge gives you a lot of security. And the other security features [0] (empirically) help reduce the occurrence of remote vulns overall with far less complexity than SELinux (which also totally weirds your system).
You sure put in a lot of effort to misconstruing me there. So many people in this thread who are responding emotionally and without the knowledge to really have a proper discussion.
Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
> You sure put in a lot of effort to misconstruing me there.
I assure you I did not, because I was on the toilet (there's a > 50% chance that this is the case with me on HN).
> without the knowledge to really have a proper discussion
This is pretty arrogant and dismissive; you don't have a great way to gauge my knowledge on this other than a no-true-scotsman on "if you knew what I knew about SELinux, you'd agree with me".
> Instead of trying to defend pledge, maybe do some more reading on SELinux and understand just how fundamentally different the approaches are, and why pledge just can't compare.
I'm not really defending pledge, and I'm not offended by the prospect that SELinux might provide superior security. I'm just trying to have a discussion with you. I will suggest that there may be other axes on which to evaluate a security solution. For example, maybe I don't want the complexity of SELinux (it is, by any measure, complex) and OpenBSD's security lets me address my threat model while avoiding SELinux' complexity. Or in other words, maybe I don't care that I can't restrict nginx to only bind to a specific port, I just don't want it serving up arbitrary files out of my filesystems: chroot to the rescue.
Here are some quotes from your other posts:
> lol, ok. You really think root can't access the devices? lol.
Super dismissive!
> If someone has remote root you are telling me they can't unhide a filesystem?
If you know about a bug in OpenBSD's chroot that lets root access any filesystem you should report it. Otherwise, you're making it up and it's not a good argument.
You might be thinking, "Hrmph, I'm just sure it's possible because of the power of root", but I might also be thinking, "Hrmph, I'm just sure there's tons of junk bugs in the monstrous SELinux code base, not to mention unintended interactions with features and other subsystems", which is why we need evidence, of which your posts have none.
> It's ["unhiding" a filesystem as root] absolutely possible. No idea about a proof of concept, but I don't even think it matters, honestly.
Yeah, here we go.
> It's cute that the OS might play some tricks to hide them from you, but at the end of the day, that's all it is doing, is hiding. Security by obscurity.
"cute" and "play some tricks" are dismissive. Again, if you've got a way to jailbreak OpenBSD's chroot you should report it. It's not security by obscurity, you can look up exactly how it works because OpenBSD is FOSS.
> lol, you clearly have no clue.
Also super dismissive.
> pledge and unveil are toys by comparison
"toys" is dismissive.
---
Multiple people have tried to engage with you to try to discuss SELinux vs. OpenBSD's other security features, and your replies have uniformly been, "do some more reading on SELinux", only more rude. If your goal here is to make friends and convince people of the merits of SELinux, my guess is you're actively losing ground with this approach.
You put words in my mouth and seemed to be misconstruing my point. I didn't assume bad faith, but I didn't assume good faith either given that.
> you have a lot of dismissive, low to no-content replies
Yeah, probably. A lot of people are saying ignorant things, like the people claiming if someone got root on SELinux they could just change the SELinux policies.
> you don't have a great way to gauge my knowledge on this
When people say something egregiously wrong, it's helps gauge. It's like if someone is telling me something about the English President I'm probably not going to put too much weight in anything they say about geopolitics.
> I'm not really defending pledge, and I'm not offended by the prospect that SELinux might provide superior security.
Well, that's great, because that's been my only real point, yet plenty of people do seem to be offended by exactly what you say you personally are not.
> I'm just trying to have a discussion with you.
I apologize profusely for being more hostile than is warranted then. I much prefer to discuss this stuff as I am passionate about it. But there are a ton of people responding emotionally with tired arguments, and it becomes a chore to reply when no good faith discussion is taking place.
> I will suggest that there may be other axes on which to evaluate a security solution. For example, maybe I don't want the complexity of SELinux (it is, by any measure, complex) and OpenBSD's security lets me address my threat model while avoiding SELinux' complexity. Or in other words, maybe I don't care that I can't restrict nginx to only bind to a specific port, I just don't want it serving up arbitrary files out of my filesystems: chroot to the rescue.
I wouldn't dispute that for a second. I agree SELinux or similar isn't needed for every use case. 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. It doesn't have to be as complex, but they should have something.
Instead, you have people suggesting and advocating for things that are not remotely similar, but are the closest and best OpenBSD has to offer along those lines, which IMO are not good enough.
> "Hrmph, I'm just sure it's possible because of the power of root",
Pretty much, yeah, except it's hardly a stretch like you are making it seem. If I can run code as root, I can find those files as devices if I'm determined enough, absolutely, even if I have to interact with devices directly and bypass the filesystem.
> Hrmph, I'm just sure there's tons of junk bugs in the monstrous SELinux code base, not to mention unintended interactions with features and other subsystems
Sure, although unlikely. 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.
The point, again, is not so much to advocate for SELinux (I prefer RSBAC myself anyway), but that OpenBSD should have something that fills the same niche. It doesn't have to be as complex, it doesn't have to be a full implementation, but they should have something. And they don't.
> "cute" and "play some tricks" are dismissive
Yes, because I'm dismissive of those technologies in the context they were brought up in.
> "toys" is dismissive.
Yup.
> Multiple people have tried to engage with you to try to discuss SELinux vs. OpenBSD's other security features, and your replies have uniformly been, "do some more reading on SELinux", only more rude.
OSS OSes like OBSD are tribal. People defend them out of emotion very often, just as much as people defend sports teams or religions. A lot of the replies are bad. There are people defending OpenBSD claiming it does what SELinux, or trying to discredit SELinux without seemingly even knowing core basics about it.
As far as I'm concerned, the quality of my replies is proportional to the comments I am replying to.
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
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
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?
> 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
[1]: https://bugs.chromium.org/p/project-zero/issues/detail?id=22...
[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...
[3]: https://rhel7stig.readthedocs.io/en/latest/medium.html#v-719...
If you don't understand a system it's by definition not secure, keep your hands away or start learning your stuff, or at least don't call it secure (the big word that includes many different meanings)