I like this a lot. It feels like the “Linux Sucks” of the BSD world.
Also to non-BSD people. Even though it doesn’t look like it at parts of it don’t take it too seriously. It points out various pain points, but it’s still pretty much like the “Linux Sucks” mentioned above. So they are true, but people can live with those things, have worked around them and actually a few parts are already fixed.
I love those things, cause they can unite developers to really tackle problems. Some of those are even things beginners could fix, which probably is also why they haven’t been fixed yet. Kind of like the “Simple”, “Beginners” or “Google Summer of Code” (or its high school version) labels on the bug tracker.
Great presentation. On a separate, but related topic, I wish OpenBSD would provide strict W^X. Meaning, applications can’t toggle writable and executable with mprotect.
What I’m talking about is also providing “if historically writable, then never executable; if historically executable, then never writable.” That truly brings the exclusivity to W^X (hence, strict W^X). For example, this code should not work, but it does in OpenBSD. If an attacker can simply mark executable a page that was previously writable, then W^X gives you nothing.
Great, so add more complexity to the kernel to keep track of memory pages that have ever been writable, for the lifetime of the process, or maybe globally!
It’s not much complexity. Take a look at HardenedBSD’s NOEXEC implementation (grep for PAX_NOEXEC), which provides the exact behavior I’m describing.
It might not be that the attacker is executing arbitrary code, but the attacker might utilize a combination of a data-only attack with ROP in order to modify an existing mprotect call to “do the devious.” Utilizing mprotect in this fashion would make ROP gadget generation easier and limit how much ROP is actually needed.
I know I hit upon a sore spot in the OpenBSD community, but I’m simply saying it’s not much work for a lot of gain. We can still differ in opinions. The great thing about having different solutions is that users can choose what works best for them. Monocultures are bad, right?
W^X buys you a lot when certain operating systems still have an executable stack & heap.
True. I’m glad I’m using an operating system that enforces non-exec stack and heap. FreeBSD’s really the one left in the dust these days.
Or use a dynamic system that doesn’t require branding ELF objects. And it’s really not that many binaries. On my desktop, it’s two rules. On my servers, zero.
If OpenBSD provided an efficient way to toggle mprotect restrictions, then users could simply disable those restrictions for only the offending applications.
I understand it very well, but I disagree with it. Having toggles doesn’t mean everyone’s going to immediately disable “ALL THE THINGS!” for every application. It simply allows the operating system developers to write stronger mitigations and let users toggle those mitigations for only those applications which misbehave with them. Thus, all the other applications benefit from the stronger and more effective mitigations.
Im following this debate for curiosity. Not taking sides but SELinux is irrelevant tangent. It’s an academic architecture (Flask) shoved into monolith not designed for it with policy language & formal model designed to express huge amount of situations. The tools sucked for a long time when I payed attention to it. Hard to integrate with apps. List goes on and on.
A simple mechanism that’s on by default, toggleable, and with breakage easy to fix should do much better than SELinux. We shouldnt compare to SELinux to a proposal unless it’s is just as awful.
The problem with toggles is that if there’s any friction to add security, no one will turn it on - it should just work. Likewise, you can’t have the toggles to turn them off be too granular, because then people will just disable them and never bother fixing them.
OpenBSD, for example has the mentioned W^X opt-out, but it’s both a pain in the ass and takes out protection for programs on the same disk slice, to discourage use.
So default the mitigation to on, and provide a toggle to turn it off.
people will just disable them and never bother fixing them.
In the nearly three years HardenedBSD has existed, we’ve seen the opposite of this. Some applications, like Chromium and Java, are the notable offenders. Suricata used to fail with the PaX model, but the main Suricata developer came to us asking for help. He fixed the “strict W^X” violation (going from RW -> RX via mprotect). And we have toggles.
It looks like Siricata’s WX problem is in PCRE’s jit. sljit in PCRE appears to map memory as RWX (pcre2-10.23/src/sljit/sljitExecAllocator.c:102), it doesn’t swap between RW and RX like, say, Firefox does, so Siricata disables PCRE’s jit everywhere W^X is enforced not only in environments with pax W^X.
This is a loss for everyone. OpenBSD gets slower regexes and everywhere else still has unsafe RWX mappings. I would rather it had been fixed to swap between mappings (like Firefox does), rather than the jit be completely disabled, which seems to be about the only way to deal with pax W^X.
No. I would guess that there are more people running OpenBSD than people actually writing and using SELinux profiles, but of course, I can’t prove it.
But in the meantime, programs that are fixed on OpenBSD (because the mitigations are turned on) are fixed on every other operating system too. Everybody wins, not only OpenBSD users.
Except applications that call mprotect(RX) on an RW page won’t get fixed, because OpenBSD doesn’t care about that. Nobody wins, especially OpenBSD users.
I think it’s more like the Linux Sucks, but also find it more entertaining than that, because it’s multiple people. Wished the recording had better quality though.
Heh, I think this is a TeX error, that W^X (write xor execute) came out as WX̂.
I liked watching the video presentation.
I like this a lot. It feels like the “Linux Sucks” of the BSD world.
Also to non-BSD people. Even though it doesn’t look like it at parts of it don’t take it too seriously. It points out various pain points, but it’s still pretty much like the “Linux Sucks” mentioned above. So they are true, but people can live with those things, have worked around them and actually a few parts are already fixed.
I love those things, cause they can unite developers to really tackle problems. Some of those are even things beginners could fix, which probably is also why they haven’t been fixed yet. Kind of like the “Simple”, “Beginners” or “Google Summer of Code” (or its high school version) labels on the bug tracker.
Great presentation. On a separate, but related topic, I wish OpenBSD would provide strict W^X. Meaning, applications can’t toggle writable and executable with mprotect.
[Comment removed by author]
What I’m talking about is also providing “if historically writable, then never executable; if historically executable, then never writable.” That truly brings the exclusivity to W^X (hence, strict W^X). For example, this code should not work, but it does in OpenBSD. If an attacker can simply mark executable a page that was previously writable, then W^X gives you nothing.
If an attacker can simply do anything, you’re past the stage where W^X would help.
[Comment removed by author]
It’s not much complexity. Take a look at HardenedBSD’s NOEXEC implementation (grep for PAX_NOEXEC), which provides the exact behavior I’m describing.
It might not be that the attacker is executing arbitrary code, but the attacker might utilize a combination of a data-only attack with ROP in order to modify an existing mprotect call to “do the devious.” Utilizing mprotect in this fashion would make ROP gadget generation easier and limit how much ROP is actually needed.
I know I hit upon a sore spot in the OpenBSD community, but I’m simply saying it’s not much work for a lot of gain. We can still differ in opinions. The great thing about having different solutions is that users can choose what works best for them. Monocultures are bad, right?
True. I’m glad I’m using an operating system that enforces non-exec stack and heap. FreeBSD’s really the one left in the dust these days.
[Comment removed by author]
Yeah, seems like I struck a nerve by acknowledging PaX’s model to be more strict and effective against exploitation.
[Comment removed by author]
Or use a dynamic system that doesn’t require branding ELF objects. And it’s really not that many binaries. On my desktop, it’s two rules. On my servers, zero.
I’m not sure that losing the ability to run JITs would be a cost that most users are willing to pay.
If OpenBSD provided an efficient way to toggle mprotect restrictions, then users could simply disable those restrictions for only the offending applications.
It seems you do not understand the philosophy behind OpenBSD. If there are toggles to be set, you’ve lost.
I understand it very well, but I disagree with it. Having toggles doesn’t mean everyone’s going to immediately disable “ALL THE THINGS!” for every application. It simply allows the operating system developers to write stronger mitigations and let users toggle those mitigations for only those applications which misbehave with them. Thus, all the other applications benefit from the stronger and more effective mitigations.
For an example of successful security toggles, see SELinux.
Im following this debate for curiosity. Not taking sides but SELinux is irrelevant tangent. It’s an academic architecture (Flask) shoved into monolith not designed for it with policy language & formal model designed to express huge amount of situations. The tools sucked for a long time when I payed attention to it. Hard to integrate with apps. List goes on and on.
A simple mechanism that’s on by default, toggleable, and with breakage easy to fix should do much better than SELinux. We shouldnt compare to SELinux to a proposal unless it’s is just as awful.
Right, because every mechanism should follow SELinux’s poor design. Yay snarky comments!
What if I told you it was possible to design a toggling mechanism that didn’t suck like SELinux?
The problem with toggles is that if there’s any friction to add security, no one will turn it on - it should just work. Likewise, you can’t have the toggles to turn them off be too granular, because then people will just disable them and never bother fixing them.
OpenBSD, for example has the mentioned W^X opt-out, but it’s both a pain in the ass and takes out protection for programs on the same disk slice, to discourage use.
So default the mitigation to on, and provide a toggle to turn it off.
In the nearly three years HardenedBSD has existed, we’ve seen the opposite of this. Some applications, like Chromium and Java, are the notable offenders. Suricata used to fail with the PaX model, but the main Suricata developer came to us asking for help. He fixed the “strict W^X” violation (going from RW -> RX via mprotect). And we have toggles.
It looks like Siricata’s WX problem is in PCRE’s jit. sljit in PCRE appears to map memory as RWX (pcre2-10.23/src/sljit/sljitExecAllocator.c:102), it doesn’t swap between RW and RX like, say, Firefox does, so Siricata disables PCRE’s jit everywhere W^X is enforced not only in environments with pax W^X.
This is a loss for everyone. OpenBSD gets slower regexes and everywhere else still has unsafe RWX mappings. I would rather it had been fixed to swap between mappings (like Firefox does), rather than the jit be completely disabled, which seems to be about the only way to deal with pax W^X.
HardenedBSD has even less market relevance than SELinux.
By that same token, same with OpenBSD.
No. I would guess that there are more people running OpenBSD than people actually writing and using SELinux profiles, but of course, I can’t prove it.
But in the meantime, programs that are fixed on OpenBSD (because the mitigations are turned on) are fixed on every other operating system too. Everybody wins, not only OpenBSD users.
Except applications that call mprotect(RX) on an RW page won’t get fixed, because OpenBSD doesn’t care about that. Nobody wins, especially OpenBSD users.
That was a great read - much better than the vaguely similar Main Linux Problems on the Desktop.
I think it’s more like the Linux Sucks, but also find it more entertaining than that, because it’s multiple people. Wished the recording had better quality though.
I’m really glad for this pdf transcript. I tried to watch the recording but it was too painful to listen to.