Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Mimi Zohar]

On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > Thinking about the blacklist keyring some more...
> 
> Are we talking about a blacklist keyring that userspace can use - or can it be
> only usable by the kernel?

The blacklist is referenced by the kernel before using a key on either
the .ima or the new .ima_mok keyring to validate a file signature.

> > My concern is more that keys can be added and removed at run time from
> > either of the .ima or the ima_mok keyrings.  The need for a blacklist
> > keyring is to prevent the key from being removed and at a later point
> > re-added.  Unfortunately, keys can be added and removed similarly from the
> > blacklist keyring as well.  Unless keys can be added, without the ability of
> > removing them, I'm not sure of the benefit of a blacklist keyring.  I assume
> > adding and removing keys requires the same write privilege.
> 
> The operations that modify the contents of a keyring in some way (link,
> unlink, clear) all operate under Write privilege.  That said, we could add a
> flag that suppresses unlink and clear on a keyring.  This could also suppress
> garbage collection of revoked and invalidated keys.

Adding the semantics at the keyring level would be better than at the
individual key level.   This new flag would prevent keys on the
blacklist from being removed.  I like this solution.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-21 11:55:40, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > > I need to think about this.  Should -EKEYREVOKED be the same as -ENOKEY 
> > > in 
> > > this case?  I guess the end result is pretty much the same from IMA view 
> > > point, but there may be a requirement to list all revoked keys...
> > 
> > When checking the blacklist, getting -EKEYREVOKED is definitely different 
> > than -ENOKEY.
> 
> Actually, I misspoke earlier.  Revoked keys are only skipped by the search if 
> a live key is found.  Should all the keys in the blacklist just be revoked so 
> that the search of the list returns either -ENOKEY (no key there) or 
> -EKEYREVOKED (the key is blacklisted)?  That might be getting too 
> over-complicated though.

>From IMA point of view both errors have the same effect - the requested 
operation is rejected.  I guess searching the blacklist keyring should return 
-EKEYREVOKED, which properly describes it's state.


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Mimi Zohar]

On Wed, 2015-10-21 at 11:52 +0100, David Howells wrote:
> Petko Manolov  wrote:
> 
> > As far as i know there is no concept of write-once to a keyring in the
> > kernel.  David will correct me if i am wrong.  I wonder how hard would it be
> > to add such functionality, in case it is missing?
> 
> Not hard, particularly if it's only an attribute that the kernel can set.

So the new flag would be set at keyring creation, similarly to
KEY_FLAG_TRUSTED_ONLY.

Mimi


--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[David Howells]

Petko Manolov  wrote:

> > > As far as i know there is no concept of write-once to a keyring in the
> > > kernel.  David will correct me if i am wrong.  I wonder how hard would
> > > it be to add such functionality, in case it is missing?
> > 
> > Not hard, particularly if it's only an attribute that the kernel can set.
> 
> Definitely kernel-only.  The other way does not appeal to me in terms of 
> security.

Nor me in terms of letting userspace lock keys into the kernel arbitrarily.

David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-21 12:49:19, David Howells wrote:
> Petko Manolov  wrote:
> 
> > > > As far as i know there is no concept of write-once to a keyring in the
> > > > kernel.  David will correct me if i am wrong.  I wonder how hard would
> > > > it be to add such functionality, in case it is missing?
> > > 
> > > Not hard, particularly if it's only an attribute that the kernel can set.
> > 
> > Definitely kernel-only.  The other way does not appeal to me in terms of 
> > security.
> 
> Nor me in terms of letting userspace lock keys into the kernel arbitrarily.

+1


Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-21 07:52:20, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 14:29 +0300, Petko Manolov wrote:
> > On 15-10-21 07:22:58, Mimi Zohar wrote:
> > > On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote:
> > > > Mimi Zohar  wrote:
> 
> > > Adding the semantics at the keyring level would be better than at the 
> > > individual key level.  This new flag would prevent keys on the blacklist 
> > > from 
> > > being removed.  I like this solution.
> > 
> > Err, what if the key's end-of-life is reached?  Revoked or not, it should 
> > go.  
> > This is more of a question rather than a statement.
> 
> Keys that have not expired should not be removed from the blacklist. 
> Otherwise 
> nothing prevents those keys from being re-loaded and used on a trusted 
> keyring. Expired keys would be flagged normally.  Any searches would result 
> in 
> -EKEYEXPIRED.

I guess the above summarizes the issue nicely.  Now let's do it. :)

> I guess there's no harm in removing expired keys from the blacklist.

I say this would be the correct behavior.


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-21 11:50:27, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > Thinking about the blacklist keyring some more...
> 
> Are we talking about a blacklist keyring that userspace can use - or can it 
> be 
> only usable by the kernel?

So far the discussion has been entirely in IMA context.  Keys can be shuffled 
around by userspace (by root and non-root users) but their only consumer is the 
IMA code.  That said, nothing prevents these keyrings to be used by the rest of 
the system.  I guess sooner or later we'll end up making them global.  Having 
more flexible CA hierarchy in the kernel is a good thing IMHO.

> > My concern is more that keys can be added and removed at run time from 
> > either of the .ima or the ima_mok keyrings.  The need for a blacklist 
> > keyring is to prevent the key from being removed and at a later point 
> > re-added.  Unfortunately, keys can be added and removed similarly from the 
> > blacklist keyring as well.  Unless keys can be added, without the ability 
> > of 
> > removing them, I'm not sure of the benefit of a blacklist keyring.  I 
> > assume 
> > adding and removing keys requires the same write privilege.
> 
> The operations that modify the contents of a keyring in some way (link, 
> unlink, clear) all operate under Write privilege.  That said, we could add a 
> flag that suppresses unlink and clear on a keyring.  This could also suppress 
> garbage collection of revoked and invalidated keys.

Agreed.  If it is needed to preserve revoked key from being GCed or unlinked, i 
assume we'll need another flag.  Current permissions model can't guarantee it.

> Note, however, that keyring searches also skip revoked and invalidated keys, 
> so that would also need dealing with.

That too.  Some scenarios may require listing all revoked keys.  I am still 
waiting to hear whether we'll need this functionality.

I assume you are not opposed to the idea of introducing such flag(s) if needed?

> > (We previously resolved the problem of keyrings being removed by userspace, 
> > even by a privileged user, by dot prefixing the keyrings.)
> 
> That doesn't stop keys being addressed directly for invalidation and 
> revocation, but you can probably manage that with permissions.

In this particular case we only deal with trusted keyrings so this is of no 
concern.


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[David Howells]

Mimi Zohar  wrote:

> > I need to think about this.  Should -EKEYREVOKED be the same as -ENOKEY in
> > this case?  I guess the end result is pretty much the same from IMA view
> > point, but there may be a requirement to list all revoked keys...
> 
> When checking the blacklist, getting -EKEYREVOKED is definitely
> different than -ENOKEY.

Actually, I misspoke earlier.  Revoked keys are only skipped by the search if
a live key is found.  Should all the keys in the blacklist just be revoked so
that the search of the list returns either -ENOKEY (no key there) or
-EKEYREVOKED (the key is blacklisted)?  That might be getting too
over-complicated though.

David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Mimi Zohar]

On Wed, 2015-10-21 at 11:55 +0100, David Howells wrote:
> Mimi Zohar  wrote:
> 
> > > I need to think about this.  Should -EKEYREVOKED be the same as -ENOKEY in
> > > this case?  I guess the end result is pretty much the same from IMA view
> > > point, but there may be a requirement to list all revoked keys...
> > 
> > When checking the blacklist, getting -EKEYREVOKED is definitely
> > different than -ENOKEY.
> 
> Actually, I misspoke earlier.  Revoked keys are only skipped by the search if
> a live key is found.  Should all the keys in the blacklist just be revoked so
> that the search of the list returns either -ENOKEY (no key there) or
> -EKEYREVOKED (the key is blacklisted)?  That might be getting too
> over-complicated though.

Right, your suggestion of adding a new flag on the keyring itself is
definitely preferable.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-21 11:52:04, David Howells wrote:
> Petko Manolov  wrote:
> 
> > As far as i know there is no concept of write-once to a keyring in the 
> > kernel.  David will correct me if i am wrong.  I wonder how hard would it 
> > be 
> > to add such functionality, in case it is missing?
> 
> Not hard, particularly if it's only an attribute that the kernel can set.

Definitely kernel-only.  The other way does not appeal to me in terms of 
security.

> > Ideally a revoked key should stay in .blacklist until it expire or the 
> > system is rebooted.
> 
> That's not quite sufficient.  Search would also need to be modified otherwise 
> the revoked key would be skipped.

OK, let's see if this is going to be a problem or not.


cheers,
Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-19 14:20:48, Mimi Zohar wrote:
> On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote:
> > This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
> > intermediate keyring that sits between .system and .ima keyrings,
> > effectively forming a simple CA hierarchy.  To successfully import a key
> > into .ima_mok it must be signed by a key which CA is in .system keyring.
> > On turn any key that needs to go in .ima keyring must be signed by CA in
> > either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.
> > 
> > IMA blacklist keyring contains all revoked IMA keys.  It is consulted
> > before any other keyring.  If the search is successful the requested
> > operation is rejected and error is returned to the caller.
> 
> Why is the blacklist so closely tied to the .ima_mok keyring?   Is this
> keyring only used for blacklisting keys on the .ima_mok keyring or for
> blacklisting keys on the .ima keyring as well?

This is all we've been using the blacklist keyring so far.  By semantics it is 
system-wide keyring so maybe the commit message should be changed.  Nothing 
prevents others from using it.

The problem is that an IMA option enables the creation of this keyring, which 
makes it IMA specific for the moment.  If it is decided that the blacklist 
keyring should be detached from it's IMA bonds then i guess two things should 
happen: 1) broader discussion (perhaps involving David); and 2) modifying the 
patches;

BTW, same applies for the MOK keyring.  If you want these to be more generally 
used i assume a discussion is in order.


Petko


> > Signed-off-by: Petko Manolov 
> > ---
> >  crypto/asymmetric_keys/x509_public_key.c |  2 ++
> >  include/keys/system_keyring.h| 24 ++
> >  security/integrity/digsig_asymmetric.c   | 14 +
> >  security/integrity/ima/Kconfig   | 17 ++
> >  security/integrity/ima/Makefile  |  1 +
> >  security/integrity/ima/ima_mok.c | 54 
> > 
> >  6 files changed, 112 insertions(+)
> >  create mode 100644 security/integrity/ima/ima_mok.c
> > 
> > diff --git a/crypto/asymmetric_keys/x509_public_key.c 
> > b/crypto/asymmetric_keys/x509_public_key.c
> > index 1970966..66dcf30 100644
> > --- a/crypto/asymmetric_keys/x509_public_key.c
> > +++ b/crypto/asymmetric_keys/x509_public_key.c
> > @@ -319,6 +319,8 @@ static int x509_key_preparse(struct 
> > key_preparsed_payload *prep)
> > goto error_free_cert;
> > } else if (!prep->trusted) {
> > ret = x509_validate_trust(cert, get_system_trusted_keyring());
> > +   if (ret)
> > +   ret = x509_validate_trust(cert, get_ima_mok_keyring());
> > if (!ret)
> > prep->trusted = 1;
> > }
> > diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
> > index b20cd88..39fd38c 100644
> > --- a/include/keys/system_keyring.h
> > +++ b/include/keys/system_keyring.h
> > @@ -35,4 +35,28 @@ extern int system_verify_data(const void *data, unsigned 
> > long len,
> >   enum key_being_used_for usage);
> >  #endif
> > 
> > +#ifdef CONFIG_IMA_MOK_KEYRING
> > +extern struct key *ima_mok_keyring;
> > +extern struct key *ima_blacklist_keyring;
> > +
> > +static inline struct key *get_ima_mok_keyring(void)
> > +{
> > +   return ima_mok_keyring;
> > +}
> > +static inline struct key *get_ima_blacklist_keyring(void)
> > +{
> > +   return ima_blacklist_keyring;
> > +}
> > +#else
> > +static inline struct key *get_ima_mok_keyring(void)
> > +{
> > +   return NULL;
> > +}
> > +static inline struct key *get_ima_blacklist_keyring(void)
> > +{
> > +   return NULL;
> > +}
> > +#endif /* CONFIG_IMA_MOK_KEYRING */
> > +
> > +
> >  #endif /* _KEYS_SYSTEM_KEYRING_H */
> > diff --git a/security/integrity/digsig_asymmetric.c 
> > b/security/integrity/digsig_asymmetric.c
> > index 4fec181..5ade2a7 100644
> > --- a/security/integrity/digsig_asymmetric.c
> > +++ b/security/integrity/digsig_asymmetric.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > 
> >  #include "integrity.h"
> > 
> > @@ -32,9 +33,22 @@ static struct key *request_asymmetric_key(struct key 
> > *keyring, uint32_t keyid)
> > 
> > pr_debug("key search: \"%s\"\n", name);
> > 
> > +   key = get_ima_blacklist_keyring();
> > +   if (key) {
> > +   key_ref_t kref;
> > +
> > +   kref = keyring_search(make_key_ref(key, 1),
> > +_type_asymmetric, name);
> > +   if (!IS_ERR(kref)) {
> > +   pr_err("Key '%s' is in ima_blacklist_keyring\n", name);
> > +   return ERR_PTR(-EKEYREJECTED);
> > +   }
> > +   }
> > +
> > if (keyring) {
> > /* search in specific keyring */
> > key_ref_t kref;
> > +
> > kref = keyring_search(make_key_ref(keyring, 1),
> > 

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-20 10:13:34, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote:
> > 
> > The code does not ties these keyrings around IMA.  The way i've done it, 
> > they are actually system wide keyrings and any other subsystem may use them.
> > 
> > Since there was no general discussion (hence agreement) that the Linux 
> > kernel need these keyrings i've put them within the IMA config options.  
> > For 
> > now only IMA users interested in creating CA hierarchy should use them.
> > 
> > > Basically, I'm trying to better understand the use case scenario.
> > 
> > To build CA hierarchy we basically need two things:
> > 
> > - system wide keyring writable at runtime, i.e. .ima_mok;
> > - system wide blacklist keyring writable at runtime, i.e. .blacklist;
> > 
> > .system is read-only and populated at kernel build time.  During the 
> > lifetime (as in runtime) of the machine we need to dynamically add tenant's 
> > certificates and IMA keys.  Without .ima_mok this can not be done easily 
> > because most of tenant's certificates are not available at krenel build 
> > time.  Most of these have one year of validity and must be replaced, while 
> > the router's uptime is typically much longer.
> > 
> > While the current kernel key code handles CA expiration it does not handle 
> > blacklisted certificates or keys.  The patch add checks to this keyring so 
> > any CA that has been compromised can't harm the system.
> > 
> > .ima_mok and .blacklist are IMA-enabled features for the moment not by 
> > semantics, but by policy.  I do think they should become system wide one 
> > day 
> > and there are good reasons to do so.
> 
> All very good!  As we discussed, this can and should be upstreamed initially 
> for IMA.
> 
> My question, however, has more to do with the last paragraph of the patch 
> description which says, "IMA blacklist keyring contains all revoked IMA keys. 
>  
> It is consulted before any other keyring.  If the search is successful the 
> requested operation is rejected and error is returned to the caller."
> 
> If the IMA blacklist keyring is for ALL IMA keys, those on the the original 
> .ima keyring and those on the .ima_mok keyring, then why is the Kconfig tied 
> to the .ima_mok keyring?  Does it make sense to have a blacklist keyring 
> without the .ima_mok keyring?  Should there be a separate Kconfig blacklist 
> keyring option?

Since having a proper CA hierarchy means access to both keyrings i never 
thought 
about separating them.  The blacklist keyring should be functional without it's 
counterpart so yes, i think it should be possible to have option for each of 
them, i.e. one for .ima_mok and one for .blacklist.

I am OK with finer granularity of the IMA options.  I wonder, though, whether 
the casual user will grasp the idea.

In short - do you want me to add separate options for the two keyrings in 
Kconfig?


Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-20 14:32:10, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> > 
> > As far as i know there is no concept of write-once to a keyring in the 
> > kernel.  David will correct me if i am wrong.  I wonder how hard would it 
> > be 
> > to add such functionality, in case it is missing?
> > 
> > Ideally a revoked key should stay in .blacklist until it expire or the 
> > system is rebooted.
> 
> Keys currently revoked return -EKEYREVOKED for a certain amount of time, 
> before being garbage collected.  Perhaps for trusted keys we could piggy back 
> on this option, returning -EKEYREVOKED, but prevent them from being garbage 
> collected?

I need to think about this.  Should -EKEYREVOKED be the same as -ENOKEY in this 
case?  I guess the end result is pretty much the same from IMA view point, but 
there may be a requirement to list all revoked keys...


Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Mimi Zohar]

On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> On 15-10-20 11:21:43, Mimi Zohar wrote:
> > On Tue, 2015-10-20 at 17:43 +0300, Petko Manolov wrote:

> 
> > Thinking about the blacklist keyring some more...  My concern is more that 
> > keys can be added and removed at run time from either of the .ima or the 
> > ima_mok keyrings.  The need for a blacklist keyring is to prevent the key 
> > from 
> > being removed and at a later point re-added. Unfortunately, keys can be 
> > added 
> > and removed similarly from the blacklist keyring as well.  Unless keys can 
> > be 
> > added, without the ability of removing them, I'm not sure of the benefit of 
> > a 
> > blacklist keyring.  I assume adding and removing keys requires the same 
> > write 
> > privilege.  (cc'ing David Howells)
> 
> As far as i know there is no concept of write-once to a keyring in the 
> kernel.  
> David will correct me if i am wrong.  I wonder how hard would it be to add 
> such 
> functionality, in case it is missing?
> 
> Ideally a revoked key should stay in .blacklist until it expire or the system 
> is 
> rebooted.

Keys currently revoked return -EKEYREVOKED for a certain amount of time,
before being garbage collected.  Perhaps for trusted keys we could piggy
back on this option, returning -EKEYREVOKED, but prevent them from being
garbage collected?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Mimi Zohar]

On Tue, 2015-10-20 at 21:42 +0300, Petko Manolov wrote:
> On 15-10-20 14:32:10, Mimi Zohar wrote:
> > On Tue, 2015-10-20 at 18:33 +0300, Petko Manolov wrote:
> > > 
> > > As far as i know there is no concept of write-once to a keyring in the 
> > > kernel.  David will correct me if i am wrong.  I wonder how hard would it 
> > > be 
> > > to add such functionality, in case it is missing?
> > > 
> > > Ideally a revoked key should stay in .blacklist until it expire or the 
> > > system is rebooted.
> > 
> > Keys currently revoked return -EKEYREVOKED for a certain amount of time, 
> > before being garbage collected.  Perhaps for trusted keys we could piggy 
> > back 
> > on this option, returning -EKEYREVOKED, but prevent them from being garbage 
> > collected?
> 
> I need to think about this.  Should -EKEYREVOKED be the same as -ENOKEY in 
> this 
> case?  I guess the end result is pretty much the same from IMA view point, 
> but 
> there may be a requirement to list all revoked keys...

When checking the blacklist, getting -EKEYREVOKED is definitely
different than -ENOKEY.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

On 15-10-20 08:48:20, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote:
> > 
> > This is all we've been using the blacklist keyring so far.  By semantics it 
> > is system-wide keyring so maybe the commit message should be changed.  
> > Nothing prevents others from using it.
> > 
> > The problem is that an IMA option enables the creation of this keyring, 
> > which makes it IMA specific for the moment.  If it is decided that the 
> > blacklist keyring should be detached from it's IMA bonds then i guess two 
> > things should happen: 1) broader discussion (perhaps involving David); and 
> > 2) modifying the patches;
> > 
> > BTW, same applies for the MOK keyring.  If you want these to be more 
> > generally used i assume a discussion is in order.
> 
> I understand these keyrings could be useful for the more general case, but 
> lets first discuss IMA.  I'm trying to understand why the blacklist is tied 
> so 
> closely to just the .ima_mok keyring in the Kconfig.  Is the need for 
> blacklisting keys any less if the key is on the .ima keyring vs. the .ima_mok 
> keyring?

The code does not ties these keyrings around IMA.  The way i've done it, they 
are actually system wide keyrings and any other subsystem may use them.

Since there was no general discussion (hence agreement) that the Linux kernel 
need these keyrings i've put them within the IMA config options.  For now only 
IMA users interested in creating CA hierarchy should use them.

> Basically, I'm trying to better understand the use case scenario.

To build CA hierarchy we basically need two things:

- system wide keyring writable at runtime, i.e. .ima_mok;
- system wide blacklist keyring writable at runtime, i.e. .blacklist;

.system is read-only and populated at kernel build time.  During the lifetime 
(as in runtime) of the machine we need to dynamically add tenant's certificates 
and IMA keys.  Without .ima_mok this can not be done easily because most of 
tenant's certificates are not available at krenel build time.  Most of these 
have one year of validity and must be replaced, while the router's uptime is 
typically much longer.

While the current kernel key code handles CA expiration it does not handle 
blacklisted certificates or keys.  The patch add checks to this keyring so any 
CA that has been compromised can't harm the system.

.ima_mok and .blacklist are IMA-enabled features for the moment not by 
semantics, but by policy.  I do think they should become system wide one day 
and 
there are good reasons to do so.


Petko
--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] Create IMA machine owner keys (MOK) and blacklist keyrings;

[Petko Manolov]

This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
intermediate keyring that sits between .system and .ima keyrings,
effectively forming a simple CA hierarchy.  To successfully import a key
into .ima_mok it must be signed by a key which CA is in .system keyring.
On turn any key that needs to go in .ima keyring must be signed by CA in
either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot.

IMA blacklist keyring contains all revoked IMA keys.  It is consulted
before any other keyring.  If the search is successful the requested
operation is rejected and error is returned to the caller.

Signed-off-by: Petko Manolov 
---
 crypto/asymmetric_keys/x509_public_key.c |  2 ++
 include/keys/system_keyring.h| 24 ++
 security/integrity/digsig_asymmetric.c   | 14 +
 security/integrity/ima/Kconfig   | 17 ++
 security/integrity/ima/Makefile  |  1 +
 security/integrity/ima/ima_mok.c | 54 
 6 files changed, 112 insertions(+)
 create mode 100644 security/integrity/ima/ima_mok.c

diff --git a/crypto/asymmetric_keys/x509_public_key.c 
b/crypto/asymmetric_keys/x509_public_key.c
index 1970966..66dcf30 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -319,6 +319,8 @@ static int x509_key_preparse(struct key_preparsed_payload 
*prep)
goto error_free_cert;
} else if (!prep->trusted) {
ret = x509_validate_trust(cert, get_system_trusted_keyring());
+   if (ret)
+   ret = x509_validate_trust(cert, get_ima_mok_keyring());
if (!ret)
prep->trusted = 1;
}
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index b20cd88..39fd38c 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -35,4 +35,28 @@ extern int system_verify_data(const void *data, unsigned 
long len,
  enum key_being_used_for usage);
 #endif
 
+#ifdef CONFIG_IMA_MOK_KEYRING
+extern struct key *ima_mok_keyring;
+extern struct key *ima_blacklist_keyring;
+
+static inline struct key *get_ima_mok_keyring(void)
+{
+   return ima_mok_keyring;
+}
+static inline struct key *get_ima_blacklist_keyring(void)
+{
+   return ima_blacklist_keyring;
+}
+#else
+static inline struct key *get_ima_mok_keyring(void)
+{
+   return NULL;
+}
+static inline struct key *get_ima_blacklist_keyring(void)
+{
+   return NULL;
+}
+#endif /* CONFIG_IMA_MOK_KEYRING */
+
+
 #endif /* _KEYS_SYSTEM_KEYRING_H */
diff --git a/security/integrity/digsig_asymmetric.c 
b/security/integrity/digsig_asymmetric.c
index 4fec181..5ade2a7 100644
--- a/security/integrity/digsig_asymmetric.c
+++ b/security/integrity/digsig_asymmetric.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "integrity.h"
 
@@ -32,9 +33,22 @@ static struct key *request_asymmetric_key(struct key 
*keyring, uint32_t keyid)
 
pr_debug("key search: \"%s\"\n", name);
 
+   key = get_ima_blacklist_keyring();
+   if (key) {
+   key_ref_t kref;
+
+   kref = keyring_search(make_key_ref(key, 1),
+_type_asymmetric, name);
+   if (!IS_ERR(kref)) {
+   pr_err("Key '%s' is in ima_blacklist_keyring\n", name);
+   return ERR_PTR(-EKEYREJECTED);
+   }
+   }
+
if (keyring) {
/* search in specific keyring */
key_ref_t kref;
+
kref = keyring_search(make_key_ref(keyring, 1),
  _type_asymmetric, name);
if (IS_ERR(kref))
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 15264b7..235b3c2 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -145,6 +145,23 @@ config IMA_TRUSTED_KEYRING
   This option requires that all keys added to the .ima
   keyring be signed by a key on the system trusted keyring.
 
+config IMA_MOK_KEYRING
+   bool "Create IMA machine owner keys (MOK) and blacklist keyrings"
+   depends on IMA_TRUSTED_KEYRING
+   default y
+   help
+  This option creates IMA MOK and blacklist keyrings.  IMA MOK is an
+  intermediate keyring that sits between .system and .ima keyrings,
+  effectively forming a simple CA hierarchy.  To successfully import a
+  key into .ima_mok it must be signed by a key which CA is in .system
+  keyring.  On turn any key that needs to go in .ima keyring must be
+  signed by CA in either .system or .ima_mok keyrings. IMA MOK is empty
+  at kernel boot.
+
+  IMA blacklist keyring contains all revoked IMA keys.  It is consulted
+  before any other keyring.  If the search is successful the