quoted

quoted

quoted

quoted

 
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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

 
 
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.