The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Roberto Sassu <roberto.sassu@polito.it>
Cc: Seiji Munetoh <seiji.munetoh@gmail.com>,
	linux-ima-user@lists.sourceforge.net,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
	Shaz <shazalive@gmail.com>
Subject: Re: [Linux-ima-user] [RFC][PATCH] ima: add default rule for initramfs files
Date: Wed, 14 Jul 2010 08:47:12 -0400	[thread overview]
Message-ID: <1279111632.2292.47.camel@localhost.localdomain> (raw)
In-Reply-To: <4C3D76AE.6090509@polito.it>

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<shazalive@gmail.com>  wrote:
> >    
> >>
> >> On Wed, Jul 14, 2010 at 3:08 AM, Seiji Munetoh<seiji.munetoh@gmail.com>
> >> wrote:
> >>      
> >>> On Thu, Jul 8, 2010 at 10:14 PM, Mimi Zohar<zohar@linux.vnet.ibm.com>
> >>> 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


      reply	other threads:[~2010-07-14 12:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-06 15:08 [RFC][PATCH] ima: add default rule for initramfs files Roberto Sassu
2010-07-08 13:14 ` Mimi Zohar
2010-07-13 22:08   ` [Linux-ima-user] " Seiji Munetoh
     [not found]     ` <AANLkTinWK9mX6lVUvWzgbh7QQ3ZItnrUE4WBJEkOqm2q@mail.gmail.com>
2010-07-14  6:29       ` Seiji Munetoh
2010-07-14  8:34         ` Roberto Sassu
2010-07-14 12:47           ` Mimi Zohar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1279111632.2292.47.camel@localhost.localdomain \
    --to=zohar@linux.vnet.ibm.com \
    --cc=eparis@redhat.com \
    --cc=linux-ima-user@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=roberto.sassu@polito.it \
    --cc=seiji.munetoh@gmail.com \
    --cc=shazalive@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox