On 25/09/2020 00:05, Pavel Machek wrote: > Hi! > >>>>> I believe you should simply delete confusing "introduction" and >>>>> provide details of super-secure system where your patches would be >>>>> useful, instead. >>>> >>>> This RFC talks about converting dynamic code (which cannot be authenticated) >>>> to static code that can be authenticated using signature verification. That >>>> is the scope of this RFC. >>>> >>>> If I have not been clear before, by dynamic code, I mean machine code that is >>>> dynamic in nature. Scripts are beyond the scope of this RFC. >>>> >>>> Also, malware compiled from sources is not dynamic code. That is orthogonal >>>> to this RFC. If such malware has a valid signature that the kernel permits its >>>> execution, we have a systemic problem. >>>> >>>> I am not saying that script authentication or compiled malware are not problems. >>>> I am just saying that this RFC is not trying to solve all of the security problems. >>>> It is trying to define one way to convert dynamic code to static code to address >>>> one class of problems. >>> >>> Well, you don't have to solve all problems at once. >>> >>> But solutions have to exist, and AFAIK in this case they don't. You >>> are armoring doors, but ignoring open windows. >> >> FYI, script execution is being addressed (for the kernel part) by this >> patch series: >> https://lore.kernel.org/lkml/20200924153228.387737-1-mic@xxxxxxxxxxx/ > > Ok. > >>> Or very probably you are thinking about something different than >>> normal desktop distros (Debian 10). Because on my systems, I have >>> python, gdb and gcc... >> >> It doesn't make sense for a tailored security system to leave all these >> tools available to an attacker. > > And it also does not make sense to use "trampoline file descriptor" on > generic system... while W^X should make sense there. Well, as said before, (full/original/system-wide) W^X may require trampfd (as well as other building-blocks). I guess most Linux deployments are not on "generic systems" anyway (even if they may be based on generic distros), and W^X contradicts the fact that users/attackers can do whatever they want on the system. > >>> It would be nice to specify what other pieces need to be present for >>> this to make sense -- because it makes no sense on Debian 10. >> >> Not all kernel features make sense for a generic/undefined usage, >> especially specific security mechanisms (e.g. SELinux, Smack, Tomoyo, >> SafeSetID, LoadPin, IMA, IPE, secure/trusted boot, lockdown, etc.), but >> they can still be definitely useful. > > Yep... so... I'd expect something like... "so you have single-purpose > system No one talked about a single-purpose system. > with all script interpreters removed, Not necessarily with the patch series I pointed out just before. > IMA hashing all the files > to make sure they are not modified, and W^X enabled. System-wide W^X is not only for memory, and as Madhavan said: "this RFC pertains to converting dynamic [writable] machine code to static [non-writable] code". > Attacker can > still execute code after buffer overflow by .... and trapoline file > descriptor addrsses that"... so that people running generic systems > can stop reading after first sentence. Are you proposing to add a "[feature-not-useful-without-a-proper-system-configuration]" tag in subjects? :)
