Re: EFI in Debian
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
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/
Reply to: