As part of a larger conversation about security measures, NX bit capability was added to DragonFly. You can turn it on or off, and it’s off by default so it doesn’t cause any surprises. As the first link in this post points out, your installed third-party software is more of a security issue than processor features, in any case.
3 Replies to “ASLR, PIE, NX, and other capital letters”
Comments are closed.
Quoting Matt from that email thread: “I just want a simple ‘here are the files and directories this program can access’, ‘here are the network ports this program can listen on’, ‘here is what the program can connect to’, ‘here are some basic resource restrictions so the program can’t crash the machine or DOS it’, … and that’s pretty much it.”
It sounds like NetBSD’s veriexec(8) subsystem might be a good place to start for that, if you haven’t already considered and rejected it. According to their documentation, it loads a specification file into the kernel telling it which files should be monitored, and can lock down file access depending on its configuration. Given that it relies on checksumming, it might be possible to retool it to work with HAMMER’s (and HAMMER2’s) built-in checksumming facilities. Maybe it could be extended to monitor directories as well? That’s just me throwing around ideas though. I’ve no idea how much work that would require to implement.
kauth(9) is probably another good reference as a much more complete framework for handling all authorization requests inside the kernel, and veriexec(8) relies on it.
Reference links:
http://netbsd.gw.com/cgi-bin/man-cgi?veriexec++NetBSD-current
https://www.netbsd.org/docs/guide/en/chap-veriexec.html
http://netbsd.gw.com/cgi-bin/man-cgi?kauth+9+NetBSD-current
“I’ve debated turning on some of these features by default but I find it to be a bit of a hard sell because these mechanisms just don’t protect well against modern attacks.”
This is making the assumption that older methods of attack are no longer used or encountered in the wild, which I think is hand-waving away existing threats that could be very effectively protected against with current mechanisms were they actually enabled.
Sure there are new classes of threats that are unaffected by current mitigations. Matt lists a few doozies. There always will be. I’d still prefer to have as many of the protections enabled as I can, and use defenses against newer threats as they become viable/available.
FWIW, I argumented the same thing on FreeBSD a couple of years ago. Not only script kiddies already have a bunch of tools to work around such mitigations, ASLR doesn’t prevent any of the recent vulnerabilities: the only way to be really secure is controlling access to your resources (both network and physical) and making sure your software has no bugs. There is no excuses for not updating your OS frequently.
OTOH, ASLR and PIE in particular brings complications for legitimate code. It’s a waste of time, IMHO.
SafeStack is nice, but it requires some extra support that is not yet in any open-source OS (and particularly not in hardenedbsd).