While looking into some problems after the last update I tried to change the kernel append parameters using heads, but didn’t find a way beside starting a rescue shell, remounting /boot read-write, editing grub.cfg, signing /boot (yes, it doesn’t allow me to override the fact that grub.cfg has unsigned changes - at least I didn’t find out how), then testing boot.
I’m used to being able to edit the kernel command line from grub - possibly protected by a password.
Just speculating but the kernel command line has potentially arbitrary functionality, so allowing any changes to the command line, allows potentially any changes to the resulting booted system. I can see why a “safety first” approach could mean that the way to make changes is the hard way.
I wouldn’t follow that argument: Since I (I’m not a real genius hacker administrator guy) found within a few minutes a way around it which could afterwards have been reversed by restoring the original grub.conf to a point at which my tampering would not have been detected anymore by heads the security argument doesn’t fit in my point of view.
Anyway it would be “security by obscurity” which is not valid security from the viewpoint of most people in the open source context.
@Kyle_Rankin did @kieran point in the right direction or is it for some other reason or didn’t just nobody think of implementing it, yet?
Yes, the reason there is a tight restriction on modifying kernel parameters is that it allows arbitrary functionality, including disabling security features in the kernel. Kernel parameters along with other contents in grub.conf are signed precisely because of this (and this is one area where Heads provides better protection than systems like SecureBoot that can only validate signatures on the binaries it executes, but not on kernel arguments or other grub.conf contents).
That said, you can still boot in unsafe mode (after all we don’t want to lock users out of their systems) and you can run kexec commands from the recovery console if you wanted to type them in manually.
In general though, the Heads developers took the approach that it is better to make it difficult to make arbitrary boot changes, and some people go the point of removing the option to go to the recovery console, while others store part of their LUKS key in the TPM and rely on the fact that going to the recovery console will change PCR values so the LUKS key cannot be recovered from the TPM w/o a reboot, as a way to protect the underlying system from arbitrary changes.
If signing a change requires the possession of an external device (like a security key) then forcing you to make a change to grub.cfg is better than simply allowing you to make run-time transient edits to the kernel boot command. You won’t be able to make the change (“evil maid”) - but you would potentially be able to restore the original grub.conf.
First of all thanks for the explanation. I’ll look some more into this later (struggling to get a grip of all the errors that I’ve got since the updates on 30th of September)
What do you mean by “unsafe mode”?
I don’t really understand this. Am I right if I simplify it to: If someone used my recovery console (to e.g. kexec) I should be warned by heads? If so, how would that warning look in PureBoot (e.g. red blinking led instead of green blinking, warning on screen)?
I read some about storing the LUKS key in TPM, but didn’t put enough afford, yet, to get a grip of that idea and develop real understanding.
I already proposed it here:
Well, yes and no 
. In my opinion there’s a point to what @kieran and @Kyle_Rankin are writing about protecting against changing the kernel parameters without the authorized user becoming aware of it.
Yes, I hate it, too when security becomes uncomfortable. But still…
I already described above, how I had to modify my kernel parameters using the rescue shell and @Kyle_Rankin mentioned the use of kexec and I’m willing to accept it this way if it helps to make me aware when someone tried to boot with different kernel parameters (tried to tamper my device).
What I do not understand is:
New value of PCR[4]: hex_value on start. But hex_value didn’t change between two starts and as I understood the idea it should’ve been changed and I should have been noticed on next boot. Or am I wrong expecting this?Yes, if they made it super easy, it would be a security–convenience tradeoff.
Well, why not super easy if it is secure anyway? I’d prefer that!
You are NOT persisting those changes. You are explicitly setting an override at boot. And if you want to make the user painfully aware that the kernel parameters had been changed you can colour the screen yellow (or red) similar to when you are doing an unsafe (ignore) boot. But this is bullshit, as the way heads works is by you sitting in front of the keyboard carefully pressing buttons and verifying that the LED on the Librem Key is GREEN. Only then will you change the kernel parameters, unlock the disk and boot into the system.
You are describing a scenario when:
The non-persistent, ephemeral, manual kernel parameter change at boot is not a real security issue in my opinion.
I’d say it is a valid opinion as long as nobody finds some real attack vector that proves the opposite.
But I follow with @kieran and @Kyle_Rankin not even taking the risk that one is proven to be wrong.
On the other hand my preferred solution is not far from yours - if we’re not already talking about the same:
When the authorized user switches the computer on she at least knows that someone started using different kernel parameters.
In this scenario I’d appreciate a lot if changing the kernel command line would be supported the same way as in grub.
@Kyle_Rankin Did I misunderstand this? Shouldn’t I be warned by heads if someone used the rescue shell?
@ChriChri The fact that you start the kernel with some crappy parameters and then turn off the computer doesn’t mean anything. The security comes from the fact that the user never entered their password to decrypt their disk. And you should not enter your password without having booted and verified the computer hasn’t been tampered with (using the Librem Key) yourself.
So you are not describing an attack in the first place.
No I don’t and I know it.
But in my opinion I don’t need to: If there is a way to make users aware of such attempts I prefer to know about them - no matter whether they succeeded.
If one day there will be this genius evil hacker that finds the attack vector you’re asking about and after that day the day follows on which that really cool security researcher finds out about genius evil hackers success and publishes it - at that day I’d like to remember that someone once started my computer using changed kernel parameters when I read that this little step had been part of genius evil hackers attack vector. 
So just in case, if I can know I’d like to know it. And if I would know it anyway the menu should give me the ability to change kernel parameters in an easy way like you propose.
@ChriChri have you used Heads and do you understand how the security of Heads works? Would you like me o explain it?
Better still, write up a wiki article on it?
I started using heads some weeks ago alongside with a LibremKey and am tryring to catch up on the topic. From my feeling there is still a lot that I need to understand.
That is one of the reasons I’m not just supporting your request on github: From my understanding (which might not be complete and wrong in parts) I cannot be sure your request doesn’t impose less security.
If you see anything wrong in what I wrote I’d be grateful to be corrected and learn more about heads.
Said that, sure, yes please! Even better would be to spread the knowledge as proposed by @kieran .
When you enter the rescue shell, Heads changes the PCR value so that you cannot extract the secret TOTP/HOTP key from the TPM from the rescue shell. You can only extract that secret when the PCR values match what the TPM is expecting, and these values get reset and re-measured at each boot.
There are some Heads users that go as far as to disable rescue mode. We allow it because it’s useful, and the combination of encrypted / partition and PureBoot protecting existing files in /boot protects the user from a malicious user with access to the laptop performing a persistent attack.