From: Vivek Goyal <vgoyal@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Eric Paris <eparis@parisplace.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>
Subject: Re: IMA: How to manage user space signing policy with others
Date: Fri, 1 Mar 2013 16:33:29 -0500 [thread overview]
Message-ID: <20130301213329.GC3457@redhat.com> (raw)
In-Reply-To: <1362166753.9158.169.camel@falcor1>
On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
[..]
> I was suggesting that a builtin appraise rule chain and everything else
> on the other chain. Userspace could replace the other chain with
> whatever they wanted, including additional appraisal rules.
>
> > > Given the fact that policy file ABI is still in testing we should be
> > > able to change semantics. (As currently user's appraise rules override
> > > kernel's appraisal rules).
>
> The userspace policy could only extend the appraisal rules. We OR the
> result of both chains, and use the more restrictive rule.
So secureboot rules will go in builtin policy. tcb appraise rules and
others will go in other policy. This other policy is replacable by
user.
We OR the results of both chains and instead of using first matching
rule, we choose a rule which is more restrictive and use that.
Is there always a clear relationship between rules. I mean one is more
restrictive than other. There can not be part-overlapping rules?
[..]
> We've already spoken about needing an additional hook or moving the
> existing bprm hook. Can we defer the memory caching requirements for
> now?
Sure, additional hook is not a concern.
I can defer caching discussion but I think it is important to discuss
it now. Because it might very well affect how do we decide to handle
multiple appraise rules/policies. So please, if possible, let us not
defer the caching requirement discussion.
My biggest concern is what if we decide to rule based caching option
and rule gets skipped because of more restrictive rule present.
appraise func=bprm_check cache_status=no
appraise fowner=root
In above case second rule will override first one and that's not what
we want.
Thanks
Vivek
next prev parent reply other threads:[~2013-03-01 21:33 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 15:13 IMA: How to manage user space signing policy with others Vivek Goyal
2013-02-28 18:51 ` Vivek Goyal
2013-02-28 20:30 ` Mimi Zohar
2013-02-28 20:57 ` Vivek Goyal
2013-03-01 1:42 ` Mimi Zohar
2013-02-28 19:23 ` Mimi Zohar
2013-02-28 20:08 ` Vivek Goyal
2013-03-01 1:45 ` Mimi Zohar
2013-02-28 21:35 ` Vivek Goyal
2013-02-28 22:20 ` Eric Paris
2013-03-01 1:49 ` Mimi Zohar
2013-03-01 12:15 ` Mimi Zohar
2013-03-01 15:28 ` Vivek Goyal
2013-03-01 18:40 ` Vivek Goyal
2013-03-01 19:39 ` Mimi Zohar
2013-03-01 21:33 ` Vivek Goyal [this message]
2013-03-03 21:42 ` Mimi Zohar
2013-03-04 15:29 ` Vivek Goyal
2013-03-04 17:46 ` Vivek Goyal
2013-03-04 18:59 ` Mimi Zohar
2013-03-04 19:15 ` Vivek Goyal
2013-03-05 1:21 ` Mimi Zohar
2013-03-05 15:18 ` Vivek Goyal
2013-03-05 20:40 ` Mimi Zohar
2013-03-05 21:53 ` Vivek Goyal
2013-03-06 15:42 ` Mimi Zohar
2013-03-06 23:55 ` Vivek Goyal
2013-03-07 1:39 ` Mimi Zohar
2013-03-07 14:36 ` Vivek Goyal
2013-03-07 15:40 ` Mimi Zohar
2013-03-07 15:53 ` Vivek Goyal
2013-03-07 17:53 ` Kasatkin, Dmitry
2013-03-07 21:56 ` Vivek Goyal
2013-03-08 8:09 ` Kasatkin, Dmitry
2013-03-08 15:40 ` Vivek Goyal
2013-03-06 15:54 ` Vivek Goyal
2013-03-06 22:48 ` Mimi Zohar
2013-03-06 23:38 ` Vivek Goyal
2013-03-07 13:38 ` Mimi Zohar
2013-03-07 14:57 ` Vivek Goyal
2013-03-04 19:19 ` Eric Paris
2013-03-04 21:47 ` Vivek Goyal
2013-03-01 2:17 ` 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=20130301213329.GC3457@redhat.com \
--to=vgoyal@redhat.com \
--cc=eparis@parisplace.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.vnet.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