Re: Grub Security Modules

[Robert Millan]

On Sat, Jan 12, 2008 at 01:54:51PM +0300, Oleg Strikov wrote:
> Good day!
> Sorry for long absence - my job takes too much time ;)
> 
> (Robert Millan)
> > hope not.. but then again, I don't like making myself an opinion on
> >something
> >before I hear what it is.
> >Oleg, please can you clarify what you intend to do?
> 
> (Uwe Hermann)
> >Is this related to TPMs and stuff? If so, please check
> >http://sourceforge.net/projects/trustedgrub
> >http://trousers.sourceforge.net/grub.html
> >Does the functionality overlap? What's the status of
> >TrustedGRUB? Should the projects be merged? etc. etc.
> 
> Yep, Uwe Hermann was in the right about Grub Security Modules destiny :)
> I'll try to describe  in a few words their main ideas:

What you describes seems mostly fine to me.  However, I'd recommend against
being associated with hardware elements whose design contemplates handcuffing
legitimate users as part of their normal operation.

Unless you can setup an owner-override in software, of course.  But I don't
know if that's even possible (it was easy to do in hardware, but they didn't
try to make it easy for us).  We can discuss about this possibility if you
like, though.

> * registered users dividual sturtup config
> (e.g. we have initial grub.cfg that e.g. calls *login* command, that e.g. :)
> takes user login and get ${login}.cfg, where we can find *password* command
> with password hash argument)

One thing that we discussed earlier is that we might want to have more than two
access levels.  For example, an administrator should be able to do anything,
but access to booting some OS entries could be allowed only to certain users.

But we didn't reach a clear idea on what interface to use yet.

> ... // init operations
> password SOME_HASH
> ... // protected section

Another thing that was discussed is to make the interface extensible to
plug-in any hash algorithm (like we do for many other things in GRUB, e.g.
disks, terminals, etc).

> * special security log keeping
> all security-connected operations leave a mark on system journal (via
> journal.mod)

Where is that written to?

> /////////
> What i've done already:
> * md5 file hash checking
> * RSA DS code porting from rsaref lib (but it's not license-correct, so i'll
> try to make this code myself)

Did you check if Gnupg has code for this?

> * log operating module (partly). I'm not a FS-specialist, so i can enbug
> only ext2 write ability. IMHO we really need FS-write (not only block write,
> but file write) in grub2.

This has been discussed before, and it seems the conclussion is that FS write
ability is not desired, because it brings too many problems.  I don't know the
specific details of the discussion, I'm afraid, but you can probably find it
in the list archives.

Perhaps a better method of logging is via serial port.  Unlike FS write, serial
port logs can not be retroactively removed by an attacker once she gains access
to the system.

> ////////
> 
> Problems:
> I've met only one problem:
> grub2 core.img verification (we need  this to make another types of
> verification reasonable)
> This can be done:
> 
> ////////
> 
> 1st way - using BIOS extentions -  it's a hot topic to discuss cause e.g. my
> MB ASUS A8N BIOS do not have  such one :( M.b. in future situation will be
> much better

What do these BIOS extensions do?  If they rely on a treacherous chip, I think
their use is completely inappropiate.  We want to empower users to setup locks
to protect themselves, not 3rd parties to setup locks that restrict users.

> 2nd way - think that grub core.img is de facto allright M.b. it's not so
> bad.
> 3rd way - let's think :)

Given that the industry seems to have little interest in providing security
hardware that doesn't treat the legitimate owner of a device as if she were
an enemy, I think the only option is moving the root of the trust chain
outside the system you're locking down.

For example, you could install an instance of GRUB in a USB stick, and assert
that you trust your USB stick not to be tampered (e.g. because you store it
in a safe).  You could even have another GRUB in the machine; this way, the
machine can still boot without your USB drive; but when you use the USB drive
to boot it, a proper trust chain is stablished.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)