[RFC 0/3] extend kexec_file_load system call

[Balbir Singh]

>>>>>  
>>>>> Command line options are not signed. I thought idea behind secureboot
>>>>> was to execute only trusted code and command line options don't enforce
>>>>> you to execute unsigned code.
>>>>>  
>>
>> You can set module.sig_enforce=0 and open up the system a bit assuming
>> that you can get a module to load with another attack
> 
> IIUC, sig_enforce bool_enable_only so it can only be enabled. Default
> value of it is 0 if CONFIG_MODULE_SIG_FORCE=n.
> 
> 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.

>>
>>>>> So it sounds like different class of security problems which you are
>>>>> referring to and not necessarily covered by secureboot or signed
>>>>> kernel.
>>>> Let me give you an example.
>>>>  
>>>> You have a secure boot setup, where the firmware/ROM validates the boot
>>>> loader.  Good, the boot loader hasn't been tampered with.
>>>>  
>>>> You interrupt the boot loader and are able to modify the command line
>>>> for the booted kernel.
>>>>  
>>>> The boot loader loads the kernel and verifies the kernel's signature.
>>>> Good, the kernel hasn't been tampered with.  The kernel starts running.
>>>>  
>>>> You've plugged in a USB drive to the device, and specified a partition
>>>> containing a root filesystem that you control to the kernel.  The
>>>> validated kernel finds the USB drive, and mounts it, and executes
>>>> your own binaries on the USB drive.
>>> You will require physical access to the machine to be able to
>>> insert your usb drive. And IIRC, argument was that if attacker has
>>> physical access to machine, all bets are off anyway.
>>>
>>
>> You don't need physical access -- your machine controller BMC can
>> do the magic for you. So its not always physical access, is it?
> 
> Well, idea was that if you have physical access to machine, then all
> bets are off. If BMC can do something which allows running unsigned
> code at ring level 0, its a problem I think from secureboot model of
> security.
> 
>>  
>>>>  
>>>>  
>>>> You run a shell on the console.  You now have control of the system,
>>>> and can mount the real rootfs, inspect it, and work out what it does,
>>>> etc.
>>>>  
>>>> At this point, what use was all the validation that the secure boot
>>>> has done?  Absolutely useless.
>>>>  
>>>> If you can change the command line arguments given to the kernel, you
>>>> have no security, no matter how much you verify signatures.  It's
>>>> the illusion of security, nothing more, nothing less.
>>>>  
>>
>> I agree, if you can change command line arguments, all bets are of lesser value
> 
> If changing command line allows execution of unsigned code at ring level
> 0, then it is a problem. Otherwise we are talking of security issues which
> are not covered by secure


I agree that from what I can see/grep there is nothing that allows unsigned
code to run at boot in ring0, but there are implications like the ones
I've mentioned above.

Attacks are typically built as a chain and every bit might matter. One could
turn off features that might lead to the system being attacked at run-time


Balbir Singh.