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
prev parent 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