*countable infinities only

Gregory Maxwell gmaxwell at gmail.com
Mon Jun 4 15:00:05 UTC 2012

On Sun, Jun 3, 2012 at 10:11 AM, Peter Jones <pjones at redhat.com> wrote:
> On 06/02/2012 05:47 PM, Gregory Maxwell wrote:
>> There is no additional security provided by the feature as so far
>> described—only security theater.   So I can't modify the kernel or
>> bootloader, great—but the kernel wouldn't have let me do that in the
>> first place unless it had an exploit. So I just put my rootkit inside
>> systemd so that it executes the kernel exploit right after reboot, and
>> the exploited kernel now silently keeps updates from being applied.
> You've sortof missed the point. A privilege escalation exploit, currently,
> can sabotage your bootloader, insert its own ahead of it, and modify the
> kernel to perpetually hide itself. Right now such exploits are generally
> bounded by selinux, which would, in most cases, stop them from performing
> the systemd trick that you describe. At that point it has escalated past
> the point where it's confined by selinux or anything else, and can do your
> trick and far worse.
> And again, there *are* "bootkit" exploits in the wild now. So any argument
> that there's no legitimate security benefit to securing the bootloader is
> prima facie false.

It's the goal that matters. Not the method. The attacker wants
persistent control of the system which can't be fixed by updates.
Replacing the kernel/bootloader is just one of many possible means to
achieve this end.

With signing, yes, replacing the bootloader doesn't "work" because
doing so will brick the machine.  But it doesn't matter, because
replacing systemd is in no way worse for the attacker than replacing
the bootloader in most situations where they would have been able to
replace the bootloader.

So two possible situations: kernel security works completely and there
is no privileged escalation exploit strong enough to defeat the kernel
imposed security— in which case you don't need any boot time
cryptographic lockdown because the kernel can simply deny the ability
to rewrite the kernel/bootloader,  or it's possible that kernel
security is buggy, in which case, the attacker doesn't really have to
care about the boot-time cryptographic lockdown because he can just
make systemd run the exploit code again at every boot— which would
accomplish the attackers goals just as well as replacing the

The case where it would matter is where the attacker can bypass kernel
security and raw-write to the disk, but can not write to kernel memory
or execute arbitrary code as the kernel or replace the update process
with a fake one... which seems really narrow to me. Not to mention the
disinterest in this as a feature is demonstrated by the fact that
while we could have officially supported inhibiting root from writing
to disk (and accessing kernel memory in order to allow them to
escalate to raw-disk-writing) which would be 100% as effective as
boot-time cryptographic lockdown, absent kernel bugs, but we haven't
and there is no public evidence (as far as I can tell) of Fedora users
asking for it.

More information about the devel mailing list