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
next prev parent 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.