[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1575403616.5241.76.camel@linux.ibm.com>
Date: Tue, 03 Dec 2019 15:06:56 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
linux-integrity@...r.kernel.org
Cc: eric.snowberg@...cle.com, dhowells@...hat.com,
matthewgarrett@...gle.com, sashal@...nel.org,
jamorris@...ux.microsoft.com, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org
Subject: Re: [PATCH v9 5/6] IMA: Add support to limit measuring keys
On Tue, 2019-12-03 at 11:45 -0800, Lakshmi Ramasubramanian wrote:
> Hi Mimi,
>
> On 12/3/2019 4:25 AM, Mimi Zohar wrote:
>
> >
> > A keyring can be created by any user with any keyring name, other than
> > ones dot prefixed, which are limited to the trusted builtin keyrings.
> > With a policy of "func=KEY_CHECK template=ima-buf keyrings=foo", for
> > example, keys loaded onto any keyring named "foo" will be measured.
> > For files, the IMA policy may be constrained to a particular uid/gid.
> > An additional method of identifying or constraining keyring names
> > needs to be defined.
> >
> > Mimi
> >
>
> Are you expecting a functionality like the following?
>
> => Measure keys added to keyring "foo", but exclude certain keys
> (based on some key identifier)
>
> Sample policy might look like below:
>
> action=MEASURE func=KEY_CHECK keyrings=foo|bar
> action=DONT_MEASURE key_magic=blah
>
> So a key with key_magic "blah" will not be measured even though it is
> added to the keyring "foo". But any other key added to "foo" will be
> measured.
>
> What would the constraining field in the key may be - Can it be SHA256
> hash of the public key? Or, some other unique identifier?
>
> Could you please clarify?
Suppose both root and uid 1000 define a keyring named "foo". The
current "keyrings=foo" will measure all keys added to either keyring
named "foo". There needs to be a way to limit measuring keys to a
particular keyring named "foo".
Mimi
Powered by blists - more mailing lists