All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: dhowells@redhat.com,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Problem with new X.509 is_hash_blacklisted() interface
Date: Wed, 21 Jun 2017 12:49:09 +0000	[thread overview]
Message-ID: <8099.1498049349@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAKv+Gu-Lwrd_=g6QNFxk5nKeh=wovstbEoc86M+0QUnwvU6ukA@mail.gmail.com>

Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> >      This can be told to skip a particular algorithm for when the caller
> >      has one precalculated.  The precalculated hash can be passed to
> >      is_hash_blacklisted().  This would typically be the case for a signed
> >      X.509 message.
> 
> This last part seems a premature optimization to me. Is there a
> performance concern preventing us from using (4) only?

Crypto stuff is relatively slow - and in the case of X.509 and PKCS#7 the
caller will already have calculated a hash.  The most likely situation
currently, I think, is that we will only have sha256 hashes in the blacklist,
and whatever we're checking will have a sha256 hash also.

Possibly, I could just pass the precalculated hash into is_data_blacklisted()
and so avoid having to call is_hash_blacklisted() from outside.

> In any case, the approach and the code look sound to me, although I
> think adding a hash of a type that we don't know how to calculate
> deserves a warning at least.

There are two issues with that:

 (1) We don't know what hashes are available without checking to see what
     modules are available.  However, to do this would involve loading the
     hash algorithm module - but we might not be in a position to do this yet
     (the blacklist is loaded before we start userspace).

 (2) A module implementing a hash algorithm might be blacklisted by the hash
     that we've been given to add to the blacklist.  I think this is a more
     general problem - and might require us to restrict blacklisting to hash
     algorithms that are built in.

David

WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: dhowells@redhat.com,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	keyrings@vger.kernel.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Problem with new X.509 is_hash_blacklisted() interface
Date: Wed, 21 Jun 2017 13:49:09 +0100	[thread overview]
Message-ID: <8099.1498049349@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAKv+Gu-Lwrd_=g6QNFxk5nKeh=wovstbEoc86M+0QUnwvU6ukA@mail.gmail.com>

Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> >      This can be told to skip a particular algorithm for when the caller
> >      has one precalculated.  The precalculated hash can be passed to
> >      is_hash_blacklisted().  This would typically be the case for a signed
> >      X.509 message.
> 
> This last part seems a premature optimization to me. Is there a
> performance concern preventing us from using (4) only?

Crypto stuff is relatively slow - and in the case of X.509 and PKCS#7 the
caller will already have calculated a hash.  The most likely situation
currently, I think, is that we will only have sha256 hashes in the blacklist,
and whatever we're checking will have a sha256 hash also.

Possibly, I could just pass the precalculated hash into is_data_blacklisted()
and so avoid having to call is_hash_blacklisted() from outside.

> In any case, the approach and the code look sound to me, although I
> think adding a hash of a type that we don't know how to calculate
> deserves a warning at least.

There are two issues with that:

 (1) We don't know what hashes are available without checking to see what
     modules are available.  However, to do this would involve loading the
     hash algorithm module - but we might not be in a position to do this yet
     (the blacklist is loaded before we start userspace).

 (2) A module implementing a hash algorithm might be blacklisted by the hash
     that we've been given to add to the blacklist.  I think this is a more
     general problem - and might require us to restrict blacklisting to hash
     algorithms that are built in.

David

WARNING: multiple messages have this Message-ID (diff)
From: dhowells@redhat.com (David Howells)
To: linux-security-module@vger.kernel.org
Subject: Problem with new X.509 is_hash_blacklisted() interface
Date: Wed, 21 Jun 2017 13:49:09 +0100	[thread overview]
Message-ID: <8099.1498049349@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAKv+Gu-Lwrd_=g6QNFxk5nKeh=wovstbEoc86M+0QUnwvU6ukA@mail.gmail.com>

Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> >      This can be told to skip a particular algorithm for when the caller
> >      has one precalculated.  The precalculated hash can be passed to
> >      is_hash_blacklisted().  This would typically be the case for a signed
> >      X.509 message.
> 
> This last part seems a premature optimization to me. Is there a
> performance concern preventing us from using (4) only?

Crypto stuff is relatively slow - and in the case of X.509 and PKCS#7 the
caller will already have calculated a hash.  The most likely situation
currently, I think, is that we will only have sha256 hashes in the blacklist,
and whatever we're checking will have a sha256 hash also.

Possibly, I could just pass the precalculated hash into is_data_blacklisted()
and so avoid having to call is_hash_blacklisted() from outside.

> In any case, the approach and the code look sound to me, although I
> think adding a hash of a type that we don't know how to calculate
> deserves a warning at least.

There are two issues with that:

 (1) We don't know what hashes are available without checking to see what
     modules are available.  However, to do this would involve loading the
     hash algorithm module - but we might not be in a position to do this yet
     (the blacklist is loaded before we start userspace).

 (2) A module implementing a hash algorithm might be blacklisted by the hash
     that we've been given to add to the blacklist.  I think this is a more
     general problem - and might require us to restrict blacklisting to hash
     algorithms that are built in.

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

  reply	other threads:[~2017-06-21 12:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-27 15:05 Problem with new X.509 is_hash_blacklisted() interface James Bottomley
2017-05-27 15:05 ` James Bottomley
     [not found] ` <1495897525.3458.7.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-05-30 10:37   ` Ard Biesheuvel
2017-05-30 10:37     ` Ard Biesheuvel
2017-06-20 16:09   ` David Howells
2017-06-20 16:09     ` David Howells
2017-06-20 16:09     ` David Howells
2017-06-20 16:09     ` David Howells
     [not found]     ` <26151.1497974983-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-06-21 12:28       ` Ard Biesheuvel
2017-06-21 12:28         ` Ard Biesheuvel
2017-06-21 12:28         ` Ard Biesheuvel
2017-06-21 12:28         ` Ard Biesheuvel
2017-06-21 12:49         ` David Howells [this message]
2017-06-21 12:49           ` David Howells
2017-06-21 12:49           ` David Howells
     [not found]           ` <8099.1498049349-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-06-21 13:07             ` Ard Biesheuvel
2017-06-21 13:07               ` Ard Biesheuvel
2017-06-21 13:07               ` Ard Biesheuvel
2017-06-21 13:07               ` Ard Biesheuvel

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=8099.1498049349@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.