Privilege drop, separation, and restricted-service operating mode in OpenBSD(sha256.net)
sha256.net
Privilege drop, separation, and restricted-service operating mode in OpenBSD
https://sha256.net/privsep.html
43 comments
Yet they are still writing everything in C.
A well-polished turd is still a turd.
A well-polished turd is still a turd.
Now name the OS that isn't written in C.
Hint: It's not Windows. It's not Linux. It's not Mac OS. It's not FreeBSD. It's not illumos...
Hint: It's not Windows. It's not Linux. It's not Mac OS. It's not FreeBSD. It's not illumos...
IIRC,Primos was written in FORTRAN (with language extensions including the ability to pass a statement number as a parameter, allowing longjmp() like behavior).
Multics (as noted above) was written in PL/I.
Multics (as noted above) was written in PL/I.
MULTICS ?
Apollo Domain OS ?
Apollo Domain OS ?
Where is your shiny rust kernel and userland useable as desktop/laptop or server? Don't pull others down just because you have yet to deliver.
Sour much?
Security is more than just auditing code to remove bugs - it's also being prepared for worst case scenarios for bugs that inevitably exist but have not yet been found.
For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient.
Something like SELinux, RSBAC, Even AppArmor is sorely needed.
For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient.
Something like SELinux, RSBAC, Even AppArmor is sorely needed.
> Something like SELinux, RSBAC, Even AppArmor
The problem with AppArmor and friends is that they are hell on earth to configure and manage.
And I'm saying that as a security conscious sysadmin !
I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall.
Of course I leave AppArmor enabled to some degree, and I'm happy if a package comes with AppArmor rules ... but I ain't gonna be sacrificing days of my life writing, tweaking, troubleshooting my own rules.
That's why I feel OpenBSD's answer is likely a good compromise. It adds a demonstrable level of security, and it doesn't stress out the sysadmin.
The problem with AppArmor and friends is that they are hell on earth to configure and manage.
And I'm saying that as a security conscious sysadmin !
I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall.
Of course I leave AppArmor enabled to some degree, and I'm happy if a package comes with AppArmor rules ... but I ain't gonna be sacrificing days of my life writing, tweaking, troubleshooting my own rules.
That's why I feel OpenBSD's answer is likely a good compromise. It adds a demonstrable level of security, and it doesn't stress out the sysadmin.
> The problem with AppArmor and friends is that they are hell on earth to configure and manage.
> I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall.
Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.
> I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall.
Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.
Rules might be a pain, but no more so than writing good firewall rules, and once done don't have to be done again.
It's not the issue some make it out to be
It's not the issue some make it out to be
> and once done don't have to be done again
Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed.
pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed.
pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
On most servers, programs are not doing drastically new things. That really isn't the issue you make it out to be.
The developer applying restrictions ahead of time can't, by nature, mitigate the types of bugs that things like SELinux can protect against.
You really have no clue about what you're talking about.
The developer applying restrictions ahead of time can't, by nature, mitigate the types of bugs that things like SELinux can protect against.
You really have no clue about what you're talking about.
Pledge and Unveil are better in one, maybe two respects.
1) The restrictions are put in place by the developer, who understand the correct and expected behaviour better than a random systems administrator.
2) Neither Pledge nor Unveil can be disabled by the user. Both SELinux and AppArmor (I don't know RSBAC) can be disabled, and is FREQUENTLY disabled because dealing with either systems are a major hassle to configure.
I'm not quite sure how SELinux is better, it's perhaps more granular, but is that better?
1) The restrictions are put in place by the developer, who understand the correct and expected behaviour better than a random systems administrator.
2) Neither Pledge nor Unveil can be disabled by the user. Both SELinux and AppArmor (I don't know RSBAC) can be disabled, and is FREQUENTLY disabled because dealing with either systems are a major hassle to configure.
I'm not quite sure how SELinux is better, it's perhaps more granular, but is that better?
> "For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient."
Does that mean that OpenBSD's mitigations are trivial to exploit? "Terrible" and "simply not sufficient" are strong words. If so, can you provide a working proof-of-concept? I keep asking this of people who make this statement because I'm genuinely interested in seeing it demonstrated as it has negative implications for me, but no one wants to spend time proving their point.
Does that mean that OpenBSD's mitigations are trivial to exploit? "Terrible" and "simply not sufficient" are strong words. If so, can you provide a working proof-of-concept? I keep asking this of people who make this statement because I'm genuinely interested in seeing it demonstrated as it has negative implications for me, but no one wants to spend time proving their point.
It'll never happen. Every single time this comes up it turns into the same thing over and over again. You must remember the person that said they'd "write a blogpost bypassing OpenBSD mitigations next week" and that's been well over a month now and, surprise, there's no blog about this.
Everything OpenBSD does is wrong and trivial to bypass but everyone's too busy to do it. Maybe the dumbest part about this is that nobody on the other side of this is making claims that these mitigations are perfect in any way.
Qualys has bypassed some OpenBSD malloc hardening features recently but then they don't go around making wild or insulting claims about how wrong and trivial they are either. Go figure.
Everything OpenBSD does is wrong and trivial to bypass but everyone's too busy to do it. Maybe the dumbest part about this is that nobody on the other side of this is making claims that these mitigations are perfect in any way.
Qualys has bypassed some OpenBSD malloc hardening features recently but then they don't go around making wild or insulting claims about how wrong and trivial they are either. Go figure.
Just replying to provide some context [1] for those who come across this comment as I think it's pretty interesting. Also OpenBSD are working on something for this [2].
[1] https://seclists.org/oss-sec/2023/q1/92
[2] https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
[1] https://seclists.org/oss-sec/2023/q1/92
[2] https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
More from Qualys: https://seclists.org/oss-sec/2023/q1/109
More from OpenBSD: https://marc.info/?l=openbsd-tech&m=167715187212393&w=2
More from OpenBSD: https://marc.info/?l=openbsd-tech&m=167715187212393&w=2
No.
It means if you look at any number of the security vulnerabilities that affected OpenBSD base system that they disclosed, or any number of bugs in third party software they haven't audieted, out of the vulns that allow root and/or rce, a lot of damage can be done on a 'secure' OpenBSD system, which something like SELinux can prevent.
Lets say Apache or something had a remote root bug (despite not running as root) that granted a shell was was pretty easy to exploit. An SELinux system can protect an unkown but actively exploited bug like that more than OpenBSD can.
The OpenBSD approach is just to keep looking and hope you've found every bug that would possibly allow for anything like that, and hope they've found them all.
It means if you look at any number of the security vulnerabilities that affected OpenBSD base system that they disclosed, or any number of bugs in third party software they haven't audieted, out of the vulns that allow root and/or rce, a lot of damage can be done on a 'secure' OpenBSD system, which something like SELinux can prevent.
Lets say Apache or something had a remote root bug (despite not running as root) that granted a shell was was pretty easy to exploit. An SELinux system can protect an unkown but actively exploited bug like that more than OpenBSD can.
The OpenBSD approach is just to keep looking and hope you've found every bug that would possibly allow for anything like that, and hope they've found them all.
Yes, SELinux and AppArmour can cover these angles in a kind of "application-agnostic" fashion. If anyone would bother using them. Practically nobody does. In the case of SELinux it's usually such a hassle that administrators immediately set the thing to permissive/disabled mode and forget about it. I think OpenBSD's efforts in securing the base system without users having to configure or meddle with the details is a pretty good compromise.
The whole thing about SELinux being so bad it's always just disabled simply isn't true.
Red Hat and Fedora have been using it in the default setup for ages, with permissive roles for unknown stuff but things that ship with RHAT locked down, and their support will even help with that.
OpenBSD's efforts in auditing are not a good compromise. It's not any compromise. It's best practices that do very little to help in the event of an actual breach.
Red Hat and Fedora have been using it in the default setup for ages, with permissive roles for unknown stuff but things that ship with RHAT locked down, and their support will even help with that.
OpenBSD's efforts in auditing are not a good compromise. It's not any compromise. It's best practices that do very little to help in the event of an actual breach.
> "OpenBSD's efforts in auditing are not a good compromise. It's not any compromise. It's best practices that do very little to help in the event of an actual breach."
> "... a remote root bug (despite not running as root) that granted a shell ..."
This example of yours would begin with an exploit (or feature) of the third-party software, which in turn managed to pivot into an exploitable hole in the kernel/base system in order to gain these escalated privileges. Securing the kernel/base system is where their focus is.
I'm not challenging the idea of a blanketing solution like AppArmor, just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient".
> "... a remote root bug (despite not running as root) that granted a shell ..."
This example of yours would begin with an exploit (or feature) of the third-party software, which in turn managed to pivot into an exploitable hole in the kernel/base system in order to gain these escalated privileges. Securing the kernel/base system is where their focus is.
I'm not challenging the idea of a blanketing solution like AppArmor, just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient".
> This example of yours would begin with an exploit (or feature) of the third-party software, which in turn managed to pivot into an exploitable hole in the kernel/base system in order to gain these escalated privileges. Securing the kernel/base system is where their focus is.
Sure, but the 'base' system doesn't really have anything that people use or that is going to have bugs. It's kind of a copout.
> just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient".
Terrible is maybe a bit strong, but they certainly are not sufficient. There are numerous exploits and exploitation paths that pledge and unveil won't prevent, but MAC/RBAC or other DAC alternatives will.
Sure, but the 'base' system doesn't really have anything that people use or that is going to have bugs. It's kind of a copout.
> just the notion that the OpenBSD team's efforts are "terrible" and "simply not sufficient".
Terrible is maybe a bit strong, but they certainly are not sufficient. There are numerous exploits and exploitation paths that pledge and unveil won't prevent, but MAC/RBAC or other DAC alternatives will.
I'm sorry, what?
Take a breath. Read it again. If you still don't understand something, think about what it is you don't understand, then state your issue clearly so I can help you.
Nothing you wrote made any sense at all. So, explain the whole thing again, I guess?
It did make sense, so I'm guessing it's just beyond your technical level of comprehension.
I'd suggest reading up more on what stuff like SELinux actually does.
I'd suggest reading up more on what stuff like SELinux actually does.
Yeah it couldn't possibly be you.
I don't see how - not to the point where you're claiming you couldn't understand any of what I said.
Why didn't other people have that problem, if it was me?
Why didn't other people have that problem, if it was me?
I'm not sure what to tell you. It didn't make sense. It doesn't make sense. There was nothing technical about what you wrote. Other people don't need to confirm that something doesn't make sense to me. I'm not making a claim, I'm telling you that it didn't make sense. What do you not understand about this?
I'm not trying to insult you or dispute what you wrote. I'm just telling you, again, that it does not make sense.
You keep repeating that all OpenBSD tries to do is audit to find bugs, but that is very obviously not all that they do to prevent exploitation and post-exploitation issues. I'm not sure why you keep doing that. This is one of the parts that doesn't make sense to me.
You say that unveil or pledge aren't enough or aren't as good as SELinux. There is nothing technical about saying that. That's just your opinion that others do not share. I'm not even commenting on whether or not I agree or disagree with you about that. However, you aren't making a point in expressing this opinion. That's something else that doesn't make sense to me.
So, do you want to try to explain what point you're trying to make again? The whole thing. All I'm getting from the things you're saying is that you love SELinux and you have almost no understanding of any other aspect of what OpenBSD does beyond auditing code.
I'm not trying to insult you or dispute what you wrote. I'm just telling you, again, that it does not make sense.
You keep repeating that all OpenBSD tries to do is audit to find bugs, but that is very obviously not all that they do to prevent exploitation and post-exploitation issues. I'm not sure why you keep doing that. This is one of the parts that doesn't make sense to me.
You say that unveil or pledge aren't enough or aren't as good as SELinux. There is nothing technical about saying that. That's just your opinion that others do not share. I'm not even commenting on whether or not I agree or disagree with you about that. However, you aren't making a point in expressing this opinion. That's something else that doesn't make sense to me.
So, do you want to try to explain what point you're trying to make again? The whole thing. All I'm getting from the things you're saying is that you love SELinux and you have almost no understanding of any other aspect of what OpenBSD does beyond auditing code.
No, you ARE making a claim, and that claim is bullshit. Certain knowledge is required to understand what I wrote and why it makes sense. And it does make sense, which is why other people were able to meaningfully respond to what I wrote.
It's fine that it doesn't make sense to YOU, but you shouldn't confuse that with it not making sense objectively, which it does.
OpenBSD doesn't literally ONLY try to audit bugs, but it is the bulk of their work and they prioritize that over addin or improving mechanisms to lockdown and prevent exploitation issues.
Others can disagree that pledge or unveil are not as good as SELinux, but they would be wrong. It isn't a subjective issue, and you would have to be rather ignorant of the differences to insist it is. SELinux removes the concept of an all powerful root user, and can grant every process the specific minimum access it needs. Pledge and unveil don't come close to offering anything like that.
Then you say I'm not making a point...even though you clearly here disagree with the point I supposedly didn't make. Are you by chance on the spectrum? Just trying to understand your issues with what I wrote, it's quite odd.
I'm not interested to explain anything further as I don't think it would be productive in proportion to the effort I would have to expend. I'm mainly just curious to see where this goes at this point.
It's fine that it doesn't make sense to YOU, but you shouldn't confuse that with it not making sense objectively, which it does.
OpenBSD doesn't literally ONLY try to audit bugs, but it is the bulk of their work and they prioritize that over addin or improving mechanisms to lockdown and prevent exploitation issues.
Others can disagree that pledge or unveil are not as good as SELinux, but they would be wrong. It isn't a subjective issue, and you would have to be rather ignorant of the differences to insist it is. SELinux removes the concept of an all powerful root user, and can grant every process the specific minimum access it needs. Pledge and unveil don't come close to offering anything like that.
Then you say I'm not making a point...even though you clearly here disagree with the point I supposedly didn't make. Are you by chance on the spectrum? Just trying to understand your issues with what I wrote, it's quite odd.
I'm not interested to explain anything further as I don't think it would be productive in proportion to the effort I would have to expend. I'm mainly just curious to see where this goes at this point.
Ah, I see you just want to get into a fight.
You've got the wrong guy, ace. Have a good day.
You've got the wrong guy, ace. Have a good day.
I believe that for the OpenBSD developers, SELinux/apparmor/seccmp are against their philosophy. [0]
While they are very powerful tools, they require complex rules maintained outside the actual code, and their complexity may lead you to disable the Security stuff entirely, rather than try to re-write the rules your distro/package came with.
OpenBSD had systrace back in the day to restrict system calls, but it suffered from the Time of Check/Time of Use/ problem, and was only used on one (sshd) program in the base system.
[0] https://www.openbsd.org/papers/hackfest2015-pledge/
While they are very powerful tools, they require complex rules maintained outside the actual code, and their complexity may lead you to disable the Security stuff entirely, rather than try to re-write the rules your distro/package came with.
OpenBSD had systrace back in the day to restrict system calls, but it suffered from the Time of Check/Time of Use/ problem, and was only used on one (sshd) program in the base system.
[0] https://www.openbsd.org/papers/hackfest2015-pledge/
Linux approach delegates security to the system administrator. Hence Linux provides containers, SELinux etc. focusing on securing the existing binaries.
OpenBSD assumes it is the programmer who is responsible for delivering secure code. Hence it provides the tools that require to modify the sources.
One can argue for one or another approach, but both at the end deliver similar reduction of the attack surface.
OpenBSD assumes it is the programmer who is responsible for delivering secure code. Hence it provides the tools that require to modify the sources.
One can argue for one or another approach, but both at the end deliver similar reduction of the attack surface.
I think that is a flawed way of looking at it. Stuff like SELinux assumes the system administrator or software can't be trusted, and provides ways to protect against future attacks while enforcing only the minimal access needed.
It isn't letting programmers off the hook, and isn't an alternate approach.
Unless you can be absolutely certain of the code you are running, which no one really can, then it's the better approach.
It isn't letting programmers off the hook, and isn't an alternate approach.
Unless you can be absolutely certain of the code you are running, which no one really can, then it's the better approach.
Aren't pledge/unveil precisely preparing for unknown bugs? Also they seem to be much easier to use than doing AppArmor chops.
I think another reason for chdir(2) is to avoid a vulnerability where you can repeatedly chain chdir("..") in the process and then chroot(".") to escape chroot.