So far I have come up with two untested, theoretical ways to circumvent the kernel signing mechanism and boot an unsigned kernel. These are both dead simple so I'll keep the explanation short. Both require an activation key, neither require a developer's key; in other words, if you can boot normally, you can do this.
First, here is how I understand the current boot process. Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init After this point, we're done with checks. Beyond here the laptop's owner has root access, but can't really replace the kernel. This exercise only addresses replacing the kernel; I do not attempt to address replacing the base system or running unsigned applications. My two attack vectors are kexec() and unsigned module based; the unsigned module method just suggests that it's possible to rewrite kexec() as a module, possibly an ugly one but it's doable nonetheless. The solutions to these are simple as well: * kexec() * CONFIG_KEXEC=n * OR add code in kexec() to check for a signed kernel * Module rewrite of kexec() * Sign modules and boot with 'enforcemodulesig' Beyond this point is fluff. It's what I just said, but with bigger words. VECTOR 1: kexec() Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init -> S00bootkernel -> kexec -l vmlinuz --command-line=nos00 -> kexec -e -> Execute kernel ~# cat /boot/config* | grep "CONFIG_KEXEC" CONFIG_KEXEC=y A user could load a copy of the kexec binary for i486 onto the system, and execute a new kernel. Further, the user could replace the entire system but keep the AK in /security/ and set up a S00bootkernel init script to load and execute a new kernel if the current version is the OLPC version. This would allow the user to boot a stripped-down Debian or Ubuntu Server system with their own custom built kernel, using the OLPC kernel as a boot loader; it would also realistically allow loading BSD or Minix or any other OS, if the OS could physically boot on the XO. VECTOR 2: unsigned module Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init -> S00bootkernel -> modprobe my-hacked-kexec-module -> kexec -l vmlinuz --command-line=nos00 -> kexec -e -> Execute kernel As far as I can tell, OLPC does not sign modules. Fedora and RHEL use signed modules and will refuse to load unsigned or invalidly signed modules if the kernel gets the "enforcemodulesig" command line parameter. kexec() is not black magic and can be forced in as a module. It just has to modify the syscall() table and take over the world (i.e. freeze every other process in the kernel, abduct the scheduler). Someone would have to possibly rewrite kexec() in an ugly way, but it could be done. Aside from needing a little more programming skill or a modularized kexec() implementation, this is the same attack vector as Vector 1. -- Bring back the Firefox plushy! http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good https://bugzilla.mozilla.org/show_bug.cgi?id=322367 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel