Re: [Linux-ima-user] [RFC][PATCH] ima: add default rule for initramfs files

[Mimi Z. <zo...@li...>]

On Wed, 2010-07-14 at 10:34 +0200, Roberto Sassu wrote:
> On 07/14/2010 08:29 AM, Seiji Munetoh wrote:
> > On Wed, Jul 14, 2010 at 2:42 PM, Shaz<sha...@gm...>  wrote:
> >    
> >>
> >> On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh<sei...@gm...>
> >> wrote:
> >>      
> >>> On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar<zo...@li...>
> >>> wrote:
> >>>        
> >>>> On Tue, 2010-07-06 at 17:08 +0200, Roberto Sassu wrote:
> >>>>          
> >>>>> This patch modifies the default policy shipped with IMA, in order to
> >>>>> avoid measurements
> >>>>> of files in the initial ramdisk. Those files can be measured early in
> >>>>> the boot process
> >>>>> by the bootloader.
> >>>>> The patch applies to latest version of the mainline kernel 2.6.35-rc4.
> >>>>>            
> >>>> Yes, the initramfs measurements are therefore redundant, as they're
> >>>> already included in the initramfs measurement, but perhaps, as the
> >>>> number of initramfs is very limited and the individual file measurements
> >>>> supplies additional information, it wouldn't hurt to keep the individual
> >>>> file measurements as well.  These measurements could potentially help in
> >>>> identifying initramfs changes.
> >>>>
> >>>> Would appreciate other opinions before accepting this change.
> >>>>          
> >>> The hash value of the initramfs is unstable since it was generated
> >>> at the time of kernel installation.
> >>> So still I want to check  the individual used file in initramfs.
> >>>        
> >> If initrd is measured by boot loader then changes to individual files should
> >> not be measured as this IS redundant. Use the new hash of the initrd as an
> >> integrity metric. Why would this not be enough?
> >>      
> > This depends on remote verifier.
> > Creating the initramfs is client side task and  the hash value of initramfs
> > will vary each clients.
> >
> > For me, validation of  current measurements is easier than validation of
> > initramfs. And it seems the overhead of this redundancy is less painful.
> >
> > But some system can validate (or trust) the initramfs measured by IPL.
> > So, I would suggest that add Kconfig option to change the default policy.

If your other suggestion, below, of adding fsmagic info to the
measurement list doesn't suffice, then defining a new command line
option, in addition to 'ima_tcb', shouldn't be a problem.

> > IMHO, if the eventlog contains fsmagic information for each measurements.
> > Verifier can skip the validation of RAMFS measurement easily.

Ok, so this takes us back to the discussion on what should be included
in the ima-nglong template. So far we have the hash algorithm(sha1,
sha256, sha512), the hash digest, filename, uid/gid, and LSM obj/subj
labels.  We can add the fsmagic after the uid/gid.  Before upstreaming
the template patches, is there anything else?  (Remember, the more info
we add, the larger the measurement list becomes, so we shouldn't add
anything superfluously.)
    
> This is true, the initramfs's digest cannot be validated by a remote 
> verifier. But in my opinion there are three main reasons for don't 
> include those files in the measurement list.
> First, this is a readonly system and measures don't change in time; so 
> if you create the image under a controlled environment and its digest 
> doesn't change you can assert it will behave correctly.

A 'controlled environment' might exist for some device types, but not
for others.

> Second, including those measurements may be very confusing for a 
> verifier since there may be multiple versions of the same object (the 
> initramfs changes very rarely in respect to other files).

Extending the ima-nglong template to include fsmagic, as Seiji
suggested, should resolve this problem.

> Lastly, a pratical use of IMA is to load a custom policy. The better 
> place to do that is the initramfs but measurements cannot be taken until 
> the policy is loaded. The only way, as Shaz mentioned in a previous 
> email, to keep track of all actions made during the boot process is that 
> you have the initramfs image measured early by the boot loader.

Yes, nobody is suggesting otherwise.  If adding fsmagic doesn't suffice,
then in addition to 'ima_tcb', another command line option could be
defined which doesn't measure initramfs files.

Mimi