On Sun, Jun 3, 2012 at 10:11 AM, Peter Jones <pjones@xxxxxxxxxx> 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 bootloader/kernel. 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
