Le mardi 10 juillet 2012 13:08:57, Russell Coker a écrit : > On Tue, 10 Jul 2012, "Thomas Preud'homme" <robotux@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 Ah yeah, I read that blog post. I like your blog by the way. Anyway, I had the exact same impression. That's why I came to the conclusion it's only useful after fixing a flaw in order to be sure the problem is fixed on next reboot. But for machine which never reboot it's indeed useless. > > 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... Of course, if you are root you can do whatever you want. That's the definition of root. > > 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. Mmmmh, indeed I didn't think about all these important files. But then, if not everything is signed it reduce the number of ways an exploit can survive accross fix+reboot to files. Yes, it's still a large surface. Actually if you go down that road you'd need to sign everything you use. No matter that the kernel, bootloader and firmware are intact if your webserver is infected and giving access to important files of your system for example. The problem is that it becomes very hard to implement for a rather small benefit (IMHO). > > > 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 ! Yes, true. That's what in the end everything you care about should be signed. But I don't think it's doable. So either we don't do secure boot at all (benefit is it requires no additional work), or we do secure boot on part of the system which guarantee that when this part of the system is upgraded to fix a flaws, it will only be booted if it was not compromised before the fix. Sort of it provides a way of knowing cryptographically if part of the system was infected or not. Best regards.
Attachment:
signature.asc
Description: This is a digitally signed message part.