linux-kernel - Re: IMA: How to manage user space signing policy with others

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Mar 2013 16:33:29 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	Eric Paris <eparis@...isplace.org>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	LSM List <linux-security-module@...r.kernel.org>
Subject: Re: IMA: How to manage user space signing policy with others

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/