From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Joshua Brindle <method@manicmethod.com>
Cc: selinux@tycho.nsa.gov, zohar@us.ibm.com, safford@watson.ibm.com
Subject: Re: [RFC]integrity: SELinux patch
Date: Mon, 16 Jul 2007 19:13:06 -0400 [thread overview]
Message-ID: <1184627586.10795.70.camel@localhost.localdomain> (raw)
In-Reply-To: <469BBB9B.3040108@manicmethod.com>
On Mon, 2007-07-16 at 14:40 -0400, Joshua Brindle wrote:
> Mimi Zohar wrote:
> > This is a first attempt to verify and measure file integrity, by
> > adding the new Linux Integrity Modules(LIM) API calls to SElinux.
> > We are planning on posting the corresponding LIM and IMA patches to
> > LKML, but would like comments/suggestions here first, particularly
> > in regards to the policy checking code in selinux_measure() called
> > from selinux_inode_permission().
> >
> > SELINUX_ENFORCE_INTEGRITY can be configured to either verify and
> > enforce integrity or to just log integrity failures. The default
> > is to just log integrity failures.
> >
> >
> I haven't reviewed the patch yet but reference to the above comments.
> This should be controlled with policy I think, its tricky though and I
> haven't thought about all the ramifications yet, I'll get back to this
> after I've thought about it.
Without the SELINUX_INTEGRITY_ENFORCE option enabled, everything is
logged, nothing is denied. This is meant to be similar to the selinux
'enforcing' option. Currently it is only a compile option, perhaps
just as enforcing is a runtime option, it should be a runtime option as
well.
> > The integrity of the SELinux metadata is verified when the xattr
> > is initially retrieved. On an integrity failure, assuming that
> > integrity verification is enforced, normal error processing occurs.
> >
> > By default, all executables and all files that are mmap'ed executable
> > are measured. This patch extends the file class with 'measure'.
> > Additional files can be measured in selinux_inode_permission()
> > based on a FILE__MEASURE policy. (As the policy call is causing too
> > many files to be measured, it is commented out.) For example, to
> > measure kernel modules add:
> >
> I'd like to say that if SELinux is controlling whether measurements
> happen or not I don't think there should be a 'default' policy in the
> module. Being able to avoid the measurement overhead for domains that we
> don't care about would be a win, fine grained as well as course grained
> measurement selections can be done with SELinux.
Ok. I can understand that as long as SELinux is making some measurement
decisions based on policy, it could just as easily make all of the
measurement decisions. At the moment though, I am having problems with
the avc_has_perm_noaudit() call in inode_permission. Without defining a
'measure' policy, it measures a lot of files. Is this because the system
is running with a targeted policy?
Are you suggesting that there is no need for the measurement calls in
file_mmap()/bprm_check_security() and that there should only be the one
measurement call in inode_permission(), which is based on policy, or
are you suggesting that the measurement calls in bprm_check_security()
and file_mmap() be based on policy?
Thanks!
Mimi Zohar
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2007-07-16 23:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-16 13:57 [RFC]integrity: SELinux patch Mimi Zohar
2007-07-16 18:40 ` Joshua Brindle
2007-07-16 23:13 ` Mimi Zohar [this message]
2007-07-16 19:23 ` Paul Moore
2007-07-17 14:30 ` Mimi Zohar
2007-07-17 14:32 ` Paul Moore
2007-07-17 14:54 ` James Morris
2007-07-18 15:05 ` Steve G
2007-09-04 20:46 ` Mimi Zohar
2007-09-04 21:08 ` Steve Grubb
[not found] ` <1188999967.5563.2.camel@localhost.localdomain>
2007-09-05 15:11 ` Integrity auditing Steve Grubb
2007-09-05 19:26 ` Mimi Zohar
2007-09-06 17:07 ` Steve Grubb
2007-09-10 20:16 ` Mimi Zohar
2007-09-12 13:25 ` Steve Grubb
2007-07-17 0:20 ` [RFC]integrity: SELinux patch James Morris
2007-07-17 13:20 ` Joshua Brindle
2007-07-17 14:44 ` James Morris
2007-07-18 21:33 ` Mimi Zohar
2007-07-17 14:52 ` Stephen Smalley
2007-07-18 21:43 ` Mimi Zohar
2007-07-19 13:08 ` Stephen Smalley
2007-07-20 18:57 ` Mimi Zohar
-- strict thread matches above, loose matches on Subject: below --
2007-08-28 22:35 Mimi Zohar
2007-08-29 4:16 ` Joshua Brindle
2007-08-29 10:14 ` Mimi Zohar
2007-09-19 19:41 ` Mimi Zohar
2007-09-19 21:04 ` Stephen Smalley
2007-09-20 1:34 ` Mimi Zohar
2007-09-20 13:12 ` Stephen Smalley
2007-09-20 21:16 ` James Morris
2007-09-21 14:13 ` Mimi Zohar
2007-09-21 14:02 ` Mimi Zohar
2007-08-30 20:58 ` Serge E. Hallyn
2007-08-30 21:12 ` Serge E. Hallyn
2007-08-31 13:15 ` 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=1184627586.10795.70.camel@localhost.localdomain \
--to=zohar@linux.vnet.ibm.com \
--cc=method@manicmethod.com \
--cc=safford@watson.ibm.com \
--cc=selinux@tycho.nsa.gov \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.