Garrett: Secure Boot and Restricted Boot

The problem here is that our argument is: deep "secure" boot support collaborates with future restriction of boot. SElinux, OTOH, does no such thing.

You can see another difference in nomenclature: one pretends to be "secure", the other explicitly states that it is "security-enhanced". Who is blatantly lying to the consumer? :-D

SELinux allows the admin to control how running software interacts, including software not critical to startup, and software that interacts with the outside world, and software that dumb/malicious users might run (inc. software they load into the box). It can restrict what compromised software can do. It brings tangible benefits to securing user-space, particularly for network facing software, despite its complexity.

Security in context: What does Secure Boot add against the type of attackers sophisticated enough to subvert the kernel and modify boot? Why _aren't_ these attackers also capable of just subverting the boot, again and again?

There's a whole class of software, and methods of attacking it, that have traditionally been viewed as "not security-sensitive", which suddenly become *front-line* once you have Secure Boot, from /etc config files, to state in /var, to kernel modules, to on-disk fs data structures (h/t Al). If those fail, then there'll still be a wealth of data read by non-privileged programmes from which to get started up and then run a kernel exploit.

The Google Chrome security bounties have demonstrated that we over-estimate the benefits of just adding additional hoops, and that the X-hats are incredibly capable at stringing together exploits of long chains of bugs into attacks.