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]

Message-ID: <1362663507.4392.422.camel@falcor1>
Date:	Thu, 07 Mar 2013 08:38:27 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Vivek Goyal <vgoyal@...hat.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 Wed, 2013-03-06 at 18:38 -0500, Vivek Goyal wrote:
> On Wed, Mar 06, 2013 at 05:48:01PM -0500, Mimi Zohar wrote:
> > On Wed, 2013-03-06 at 10:54 -0500, Vivek Goyal wrote:

[...]
> > > - Because policy can be replaced easily, some of the functionality
> > >   will automatically be disabled. (because associated policy is not
> > >   there any more). And this can be very unintutive.
> > 
> > Limiting the additional functionality to a single policy, is wrong. A
> > new policy option (eg. memlock) or even action primitive (eg.
> > appraise_memlock) should be defined, allowing any policy to achieve the
> > same results.
> 
> Sorry I did not get this part. How does any policy achieve the same
> results.

This discussion has gone through many twists and turns - original direct
crypto calls to verify appended signature, 'optional' policy flag,
locking memory, fixing appraisal results, differentiating ima vs. evm
appraisal results, iint caching, merging policies vs. either/or policy, 
new policy memory lock option/action, separating policy from locking
memory, and now exporting integrity calls.

Once you resolve the 'special' processing (eg. memory locking issue)
being tied to the policy, either by removing the requirement or by
defining a new policy option/action primitive, you'll be able to resolve
your policy requirements, without merging rules or limiting
functionality for other policies.

Limiting functionality (eg. kexec) to a single builtin policy is
unacceptable.  The same mechanism, that the builtin kmem_lock policy
uses to make kexec permissible, should be available to all policies.  It
is then up to the system administrator to define an appropriate policy.

thanks,

Mimi

--
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/