Russell King - ARM Linux <linux at armlinux.org.uk> writes: > On Wed, Jul 20, 2016 at 01:45:42PM +1000, Balbir Singh wrote: >> > IOW, if your kernel forced signature verification, you should not be >> > able to do sig_enforce=0. If you kernel did not have >> > CONFIG_MODULE_SIG_FORCE=y, then sig_enforce should be 0 by default anyway >> > and you are not making it worse using command line. >> >> OK.. I checked and you are right, but that is an example and there are >> other things like security=, thermal.*, nosmep, nosmap that need auditing >> for safety and might hurt the system security if used. I still think >> think that assuming you can pass any command line without breaking security >> is a broken argument. > > Quite, and you don't need to run code in a privileged environment to do > any of that. > > It's also not trivial to protect against: new kernels gain new arguments > which older kernels may not know about. No matter how much protection > is built into older kernels, newer kernels can become vulnerable through > the addition of further arguments. Indeed. A whitelist of allowed command line arguments is the only option. But given the existing syscall has shipped without a whitelist of command line arguments, you can't add a whitelist now without potentially breaking someone's setup. Getting back to the device tree, we could similarly have a whitelist of nodes/properties that we allow to be passed in. At least for stdout-path, I can't really see how that would significantly help an attacker, but I'm all ears if anyone has ideas. > Also, how sure are we that there are no stack overflow issues with kernel > command line parsing? Can we be sure that there's none? This is > something which happens early in the kernel boot, before the full memory > protections have been set up. Yeah that's also a good point. More so for the device tree, because the parsing is more complicated. I think there has been some work done on fuzzing libfdt, but we should probably do more. cheers
