Re: [Linux-ima-user] Chain of trust in IMA and IMA for Ubuntu!

[Vladimir 'φ-coder/p. S. <ph...@gm...>]

On 14.01.2014 21:21, Mimi Zohar wrote:
> On Tue, 2014-01-14 at 19:30 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote: 
>> On 14.01.2014 16:59, Peter Jones wrote:
>>> PCR, as well as having grub2 do so for its config, the kernel, and any
>>> initramfses to be loaded.  Doing so on a UEFI machine isn't a particularly
>>> difficult change to grub2 - but you may face the same political
>>> problems.  It's probably worth asking Vladimir Serbinenko, who I've
>>> Cced, as he's the upstream maintainer of grub2.
> 
>> GRUB2 has RSA/DSA gnupg signature checking. Currently in mainstream it
>> supports only detached GPG signatures but I have a branch where I work
>> on PE signatures (phcoder/file_types). For me we could use either. In
>> the same branch I also work on implementing partial checks (check only
>> files needed to satisfy EFI stuff).  This approach gives similar (if not
>> better) security gurantees (unless rollback is a problem, usually it's
>> not and preventing it prevents normal activity as backup restore as
>> well) but has no political problems. The only part which may be
>> politically problematic is enforcing this check depending on EFI
>> variables but this would be a tiny patch remaining. Another advantage of
>> this approach is easy integration with coreboot (just use GRUB2 as
>> payload) I didn't finish this approach yet. Missing parts are file types
>> (I still wait for answer from Peter Jones as to which files needs to be
>> checked) and PE signatures (WIP).
> 
> Thanks for responding!  In order to verify the signatures, you're
> already calculating file hashes.  Would it be possible to also extend
> the TPM with these hashes and add them to the measurement list?
>
It's difficult to see which modules GRUB loads and in which order. I'd
prefer using a key to tie together kernel and modules. This way whole
GRUB core+modules+signed kernel could be single block for TPM.
GRUB is part of GNU. As FSF project whether it has any TPM depends on
FSF politics. I'm not up to a flamewar of how and why, I'm just stating
the fact that as long as FSF has anti-TPM policy any admission of
TPM-related code needs approval by FSF (approval on generic
functionality, not on details) and I'd recommend taking it to them.
I'm open to extending signatures with additional features but not a
single TPM hash write could occur in upstream GRUB without FSF approval.
Neverthelss I'd like to be kept in the loop about any branch that would
use TPM.


> thanks,
> 
> Mimi
> 
>