On Tue, 10 Jul 2012, "Thomas Preud'homme" <robo...@celest.fr> wrote: > When the flaws was exploited, then the attacker had sufficient access to > change e.g. EFI and could thus have done whatever nasty things he wanted > on the system. And as long as the system is not rebooted, nothing can > prevent it to do so.
http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/ I've written a blog post about some of the issues related to secure boot at the above URL. Some of the problems include the fact that workstations have a lot of uptime nowadays (so a machine that has a trojan in RAM is likely to stay that way for a while) and that an attack which is performed once can be performed on every boot. http://www.coker.com.au/selinux/play.html Also in that post I address the apparently common misconception that "secure boot" makes it impossible for a remote "root" user to damage the system. As an aside I have a Wheezy based SE Linux Play Machine online right now, it demonstrates "root" as an account that can't damage the system - but that "root" account also can't be used for system administration... > From this, I came to the conclusion that secure boot only provides > additional security when the administrator discover the flaws, either via > a > CVE/DSA/whatever announce, or because he realized the system is having a > strange behavior (ex: something suspicious in the logs). Then, he will try > to patch the flaw by upgrading its kernel and want to be sure at reboot > that the malware didn't manage to infect the patched kernel in the mean > time. In other words, the administrator want to be sure at reboot that the > problem is solved (at least for this flaw, there could be other flaws of > course but they need to be found). The problem with that is the wide variety of ways that the system is configured. We would need some way to verify, inspect, or revert every change to a security sensitive config file to restore a compromised system. Signing every config file isn't viable as you can't sign it locally (and taking every changed config file from a disconnected system is a PITA). Inspection isn't good as even competent sysadmins will have a hard time recognising every potential mistake in a config file. Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we could have a patch management system to treat all changes to /etc as patches. This might be viable. > At last, there is the question of what to sign. If we want secure boot to > be really useful then we should sign all the way from the bootloader to > the kernel modules. No. The easiest way of doing that properly would be to have a filesystem that includes signing and not allow high integrity processes (either processes with a high integrity label according to Biba or a system domain in SE Linux) to read files that weren't signed. The harder way of doing that would be to have the system dynamic loader, every interpreter (the shell, Perl, etc), and every important process that reads a config file (IE most daemons) check signatures on all files. There's really not much benefit in having a signed kernel and modules if you can have a trojan loaded from /root/.bashrc ! -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207102108.57283.russ...@coker.com.au
