On 06/19/2018 02:52 AM, Kees Cook wrote:
Adding Florian to CC, but if something gets CET enabled, it really shouldn't have a way to turn it off. If there's a way to turn it off, all the ROP research will suddenly turn to exactly one gadget before doing the rest of the ROP: turning off CET. Right now ROP is: use stack-pivot gadget, do everything else. Allowed CET to turn off will just add one step: use CET-off gadget, use stack-pivot gadget, do everything else. :P Following Linus's request for "slow introduction" of new security features, likely the best approach is to default to "relaxed" (with a warning about down-grades), and allow distros/end-users to pick "forced" if they know their libraries are all CET-enabled.
The dynamic linker can tell beforehand (before executing any user code) whether a process image supports CET. So there doesn't have to be anything gradual about it per se to preserve backwards compatibility.
The idea to turn off CET probably comes from the desire to support dlopen. I'm not sure if this is really necessary because the complexity is rather nasty. (We currently do something similar for executable stacks.) I'd rather have a switch to turn off the feature upon process start. Things like NSS and PAM modules need to be recompiled early. (I hope that everything that goes directly to the network via custom protocols or hardware such as smartcards is proxied via daemons these days.)
Thanks, Florian
