From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Valdis.Kletnieks@vt.edu, linux-security-module@vger.kernel.org,
safford@watson.ibm.com, serue@linux.vnet.ibm.com,
kjhall@linux.vnet.ibm.com, zohar@us.ibm.com,
linux-kernel@vger.kernel.org, disec-devel@lists.sourceforge.net,
selinux@tycho.nsa.gov
Subject: Re: [RFC] [Patch 1/1] IBAC Patch
Date: Wed, 14 Mar 2007 05:46:55 -0400 [thread overview]
Message-ID: <1173865615.5793.1.camel@localhost.localdomain> (raw)
In-Reply-To: <20070313153131.GB29812@vino.hallyn.com>
On Tue, 2007-03-13 at 10:31 -0500, Serge E. Hallyn wrote:
> Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):
> > On Thu, 2007-03-08 at 22:19 -0500, Valdis.Kletnieks@vt.edu wrote:
> > > On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said:
> > > > This is a request for comments for a new Integrity Based Access
> > > > Control(IBAC) LSM module which bases access control decisions
> > > > on the new integrity framework services.
> > > >
> > > > (Hopefully this will help clarify the interaction between an LSM
> > > > module and LIM module.)
> > >
> > > OK, between this and the additional LIM hooks I didn't notice in an earlier
> > > patch, we're starting to see the API. The only problem is that although
> > > it may be the right API for *your* code, I suspect it's a non-starter without
> > > a discussion about whether it's the right *generic* API for an LIM (which will
> > > require at least one dramatic bun fight about what "Integrity" means).
> >
> > Absolutely, we need to make sure that the set of LIM hooks is complete and that
> > nothing is missing in order to implement different types of LIM providers. I'm
> > copying the digsig mailing list for their input on requirements, which this API
> > might not satisfy or perhaps address.
>
> (Could you resend the IBAC patch to the disec list as well?)
Sure, I'm just about to post a new version of IBAC with the changes based on
comments from the lsm and lkml lists.
> Is IBAC basically a 'demo' lsm? It only hooks bprm_security, so you
> can't execute anything with a bad hash, right? So really if you were to
> also hook mmap, this would completely do away with the need for digsig?
> IBAC is automatically able to use any integrity measurement modules you
> write, whether they use gpg like digsig does right now, or use the tpm?
You're absolutely correct on all accounts.
> It also shows how simple it would be to hook selinux, though I guess
> there are several ways we might want to hook selinux - 1. to check only
> security.selinux xattrs, 2. to check integrity of entry point types, 3.
> to check integrity of any files labeled by the integrity measurement
> module as needing to be checked.
Correct. Verifying the integrity of security.selinux xattrs would require
adding security.selinux to /etc/evm.conf and calls within SELinux to
integrity_verify_metadata() as needed. Verifying the integrity of files,
would require labeling the files with integrity measurements and
adding calls within SELinux to integrity_verify_data() as needed.
> Is there any way for the LSM itself to direct which data and metadata
> will be measured? It looks like this is done by separately configuring
> the integrity measurement module - which seems fine to me.
Actually the current EVM implementation as an integrity provider relies on
an LSM module, or for that matter any other kernel module, to make calls
to the integrity API: integrity_verify_metadata(), integrity_verify_data(),
and integrity_measure(). The decision as to which files are to be measured
is left up to the LSM module. For example, as you previously noted, IBAC
only verifies the metadata and data integrity of executables, whereas SLIM
verifies the metadata and data integrity of SYSTEM level files and all
executables.
Mimi Zohar
next prev parent reply other threads:[~2007-03-14 10:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 22:58 [RFC] [Patch 1/1] IBAC Patch Mimi Zohar
2007-03-08 23:08 ` Randy Dunlap
2007-03-09 13:19 ` Mimi Zohar
2007-03-09 18:26 ` Randy Dunlap
2007-03-09 3:19 ` Valdis.Kletnieks
2007-03-09 15:07 ` Serge E. Hallyn
2007-03-12 21:47 ` Mimi Zohar
2007-03-13 15:31 ` Serge E. Hallyn
2007-03-14 9:46 ` Mimi Zohar [this message]
2007-03-14 2:27 ` Seth Arnold
2007-03-14 11:25 ` Mimi Zohar
2007-03-14 18:48 ` Seth Arnold
-- strict thread matches above, loose matches on Subject: below --
2007-03-14 9:49 Mimi Zohar
2007-06-18 20:48 [RFC][Patch " Mimi Zohar
2007-06-19 22:23 ` Serge E. Hallyn
2007-06-20 11:52 ` Mimi Zohar
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=1173865615.5793.1.camel@localhost.localdomain \
--to=zohar@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=disec-devel@lists.sourceforge.net \
--cc=kjhall@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=safford@watson.ibm.com \
--cc=selinux@tycho.nsa.gov \
--cc=serge@hallyn.com \
--cc=serue@linux.vnet.ibm.com \
--cc=zohar@us.ibm.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