Why a mount option? I’m not too familiar with OpenBSD, so I have to assume this somehow makes more sense in the context of the rest of the OS. But intuitively I would expect such a flag to operate at the program rather than the filesystem level.
It’d be too easy to get away with just toggling it off and forgetting. This means the base system won’t have to suffer, but unbreaking W\^X for packages is a big enough carrot to fix them all.
I’m not a big fan of doing a mount option. Since all your third-party applications are going to be in /usr/local/bin, if only a single application (Mongo? NodeJS? Chromium?) requires RWX pages, then you have to disable W^X for all third-party applications.
OpenBSD will eventually provide ELF binary tagging, probably not dissimilar to how PaX does it with paxctl. I’m not a fan of modifying binaries, either. It’s heavy-handed and ruins host-based IDS solutions that validate executable file hashes. Additionally, anytime you reinstall/upgrade an application, you have to manually retag it. This is a maintenance nightmare.
HardenedBSD allows users to maintain a dynamic list of applications in which to enable/disable certain exploit mitigations, like W^X. This is kept in a config file that is sent to a kernel module. At execve(2) time, the kernel module will set the per-application flags, disabling/enabling features as requested by the user. Additionally, we are working on the same type of feature, but using filesystem extended attributes (FS XATTR) instead of a dynamically-loaded list. I think OpenBSD should look into the same type of functionality.
The rationale for the mount point option is to grant sys admin some level of control. For instance, I can’t enable W|X by copying a binary to my home directory and setting a flag. I think the plan is to make workarounds awkward, so more attention is directed at the underlying problem.
(Probably a better response to spinda. Lousy threading.)
The idea is that there must be no convenient way to enable/disable W^X at will.
In the ELF tagging scheme being developed, the WX-allowed flag is set on the main executable via an option passed to the linker. If that linker option is not used (default), WX is not allowed.
WX is allowed only if the ELF flag in the binary and the mount flag for the filesystem are both set.
From the point of view of enforcement policy, it works like pledge() in the sense that a promise not to use WX cannot be broken.
Shared libaries which are opened later on and try to WX cause the program to end.
Not really. Theo has been talking about mandatory W^X and ecosystem readiness for years. I think what’s changed is that Theo expects to still be able to run Firefox with this in place.
But isn’t the timing of it being enabled a little coincidental? It’s supposedly been around fifteen years since OpenBSD introduced W^X into the codebase, and only now, after an article showing OpenBSD not enforcing it, does it get enforced.
What’s the fstab thing referred to?
Why a mount option? I’m not too familiar with OpenBSD, so I have to assume this somehow makes more sense in the context of the rest of the OS. But intuitively I would expect such a flag to operate at the program rather than the filesystem level.
It’d be too easy to get away with just toggling it off and forgetting. This means the base system won’t have to suffer, but unbreaking W\^X for packages is a big enough carrot to fix them all.
I’m not a big fan of doing a mount option. Since all your third-party applications are going to be in /usr/local/bin, if only a single application (Mongo? NodeJS? Chromium?) requires RWX pages, then you have to disable W^X for all third-party applications.
OpenBSD will eventually provide ELF binary tagging, probably not dissimilar to how PaX does it with paxctl. I’m not a fan of modifying binaries, either. It’s heavy-handed and ruins host-based IDS solutions that validate executable file hashes. Additionally, anytime you reinstall/upgrade an application, you have to manually retag it. This is a maintenance nightmare.
HardenedBSD allows users to maintain a dynamic list of applications in which to enable/disable certain exploit mitigations, like W^X. This is kept in a config file that is sent to a kernel module. At execve(2) time, the kernel module will set the per-application flags, disabling/enabling features as requested by the user. Additionally, we are working on the same type of feature, but using filesystem extended attributes (FS XATTR) instead of a dynamically-loaded list. I think OpenBSD should look into the same type of functionality.
The rationale for the mount point option is to grant sys admin some level of control. For instance, I can’t enable W|X by copying a binary to my home directory and setting a flag. I think the plan is to make workarounds awkward, so more attention is directed at the underlying problem.
(Probably a better response to spinda. Lousy threading.)
The idea is that there must be no convenient way to enable/disable W^X at will.
In the ELF tagging scheme being developed, the WX-allowed flag is set on the main executable via an option passed to the linker. If that linker option is not used (default), WX is not allowed. WX is allowed only if the ELF flag in the binary and the mount flag for the filesystem are both set.
From the point of view of enforcement policy, it works like pledge() in the sense that a promise not to use WX cannot be broken. Shared libaries which are opened later on and try to WX cause the program to end.
[Comment removed by author]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/mount/mntopts.h.diff?r1=1.16&r2=1.17&f=h
I seem to remember reading that Go uses W|X for closures. Am I wrong?
Is this due to the article that showed OpenBSD wasn’t enforcing W^X?
Not really. Theo has been talking about mandatory W^X and ecosystem readiness for years. I think what’s changed is that Theo expects to still be able to run Firefox with this in place.
But isn’t the timing of it being enabled a little coincidental? It’s supposedly been around fifteen years since OpenBSD introduced W^X into the codebase, and only now, after an article showing OpenBSD not enforcing it, does it get enforced.
Perhaps it is a response to my blog post: http://www.tedunangst.com/flak/post/now-or-never-exec
There was also a rather acrimonious thread about this very topic a mere 13 years ago as well: http://marc.info/?t=105058908400003&r=1&w=2