All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, dhowells@redhat.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Kirill Marinushkin <k.marinushkin@gmail.com>,
	security@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v5] security/keys: rewrite all of big_key crypto
Date: Sun, 17 Sep 2017 06:04:57 +0000	[thread overview]
Message-ID: <20170917060457.GB10599@zzz.localdomain> (raw)
In-Reply-To: <20170916130533.23036-1-Jason@zx2c4.com>

Hi Jason,

On Sat, Sep 16, 2017 at 03:05:33PM +0200, Jason A. Donenfeld wrote:
> -
> -		ret = big_key_gen_enckey(enckey);
> -		if (ret)
> -			goto err_enckey;
> +		ret = get_random_bytes_wait(enckey, ENC_KEY_SIZE);
> +		if (unlikely(ret))
> +			goto error;

This should jump to 'err_enckey', otherwise it will leak 'enckey'.

Otherwise the changes all look good; after fixing the above, feel free to add my
Reviewed-by.  Yes, AES-GCM is the right choice here.  It is, however, almost
certainly the case that if someone can modify your swap partition, they can
already own your system in many other ways, so the "authenticated" portion of
"authenticated encryption" may not actually buy much in this situation :-)

The patch is a little long and perhaps should be split into several patches,
each of which fixes one bug; but see what David thinks.

I should also note, that while there definitely were some inadmissible bugs
here, the support for encrypting big_key's was only added recently, in the v4.7
kernel.  And obviously not encrypting at all is at least as much as a
"vulnerability" as using weak encryption.  I'm also a little skeptical that
people actually care enough about big_key's for it to be worthwhile to mark a
rewrite like this for stable, though I suppose it wouldn't be *too* hard to at
least cherry-pick this to 4.9 if you wanted.  (There is a small conflict so
you'd have to send the backport yourself after this goes into mainline.)

Eric

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, dhowells@redhat.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Kirill Marinushkin <k.marinushkin@gmail.com>,
	security@kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v5] security/keys: rewrite all of big_key crypto
Date: Sat, 16 Sep 2017 23:04:57 -0700	[thread overview]
Message-ID: <20170917060457.GB10599@zzz.localdomain> (raw)
In-Reply-To: <20170916130533.23036-1-Jason@zx2c4.com>

Hi Jason,

On Sat, Sep 16, 2017 at 03:05:33PM +0200, Jason A. Donenfeld wrote:
> -
> -		ret = big_key_gen_enckey(enckey);
> -		if (ret)
> -			goto err_enckey;
> +		ret = get_random_bytes_wait(enckey, ENC_KEY_SIZE);
> +		if (unlikely(ret))
> +			goto error;

This should jump to 'err_enckey', otherwise it will leak 'enckey'.

Otherwise the changes all look good; after fixing the above, feel free to add my
Reviewed-by.  Yes, AES-GCM is the right choice here.  It is, however, almost
certainly the case that if someone can modify your swap partition, they can
already own your system in many other ways, so the "authenticated" portion of
"authenticated encryption" may not actually buy much in this situation :-)

The patch is a little long and perhaps should be split into several patches,
each of which fixes one bug; but see what David thinks.

I should also note, that while there definitely were some inadmissible bugs
here, the support for encrypting big_key's was only added recently, in the v4.7
kernel.  And obviously not encrypting at all is at least as much as a
"vulnerability" as using weak encryption.  I'm also a little skeptical that
people actually care enough about big_key's for it to be worthwhile to mark a
rewrite like this for stable, though I suppose it wouldn't be *too* hard to at
least cherry-pick this to 4.9 if you wanted.  (There is a small conflict so
you'd have to send the backport yourself after this goes into mainline.)

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiggers3@gmail.com (Eric Biggers)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v5] security/keys: rewrite all of big_key crypto
Date: Sat, 16 Sep 2017 23:04:57 -0700	[thread overview]
Message-ID: <20170917060457.GB10599@zzz.localdomain> (raw)
In-Reply-To: <20170916130533.23036-1-Jason@zx2c4.com>

Hi Jason,

On Sat, Sep 16, 2017 at 03:05:33PM +0200, Jason A. Donenfeld wrote:
> -
> -		ret = big_key_gen_enckey(enckey);
> -		if (ret)
> -			goto err_enckey;
> +		ret = get_random_bytes_wait(enckey, ENC_KEY_SIZE);
> +		if (unlikely(ret))
> +			goto error;

This should jump to 'err_enckey', otherwise it will leak 'enckey'.

Otherwise the changes all look good; after fixing the above, feel free to add my
Reviewed-by.  Yes, AES-GCM is the right choice here.  It is, however, almost
certainly the case that if someone can modify your swap partition, they can
already own your system in many other ways, so the "authenticated" portion of
"authenticated encryption" may not actually buy much in this situation :-)

The patch is a little long and perhaps should be split into several patches,
each of which fixes one bug; but see what David thinks.

I should also note, that while there definitely were some inadmissible bugs
here, the support for encrypting big_key's was only added recently, in the v4.7
kernel.  And obviously not encrypting at all is at least as much as a
"vulnerability" as using weak encryption.  I'm also a little skeptical that
people actually care enough about big_key's for it to be worthwhile to mark a
rewrite like this for stable, though I suppose it wouldn't be *too* hard to at
least cherry-pick this to 4.9 if you wanted.  (There is a small conflict so
you'd have to send the backport yourself after this goes into mainline.)

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org, dhowells@redhat.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Kirill Marinushkin <k.marinushkin@gmail.com>,
	security@kernel.org, stable@vger.kernel.org
Subject: [kernel-hardening] Re: [PATCH v5] security/keys: rewrite all of big_key crypto
Date: Sat, 16 Sep 2017 23:04:57 -0700	[thread overview]
Message-ID: <20170917060457.GB10599@zzz.localdomain> (raw)
In-Reply-To: <20170916130533.23036-1-Jason@zx2c4.com>

Hi Jason,

On Sat, Sep 16, 2017 at 03:05:33PM +0200, Jason A. Donenfeld wrote:
> -
> -		ret = big_key_gen_enckey(enckey);
> -		if (ret)
> -			goto err_enckey;
> +		ret = get_random_bytes_wait(enckey, ENC_KEY_SIZE);
> +		if (unlikely(ret))
> +			goto error;

This should jump to 'err_enckey', otherwise it will leak 'enckey'.

Otherwise the changes all look good; after fixing the above, feel free to add my
Reviewed-by.  Yes, AES-GCM is the right choice here.  It is, however, almost
certainly the case that if someone can modify your swap partition, they can
already own your system in many other ways, so the "authenticated" portion of
"authenticated encryption" may not actually buy much in this situation :-)

The patch is a little long and perhaps should be split into several patches,
each of which fixes one bug; but see what David thinks.

I should also note, that while there definitely were some inadmissible bugs
here, the support for encrypting big_key's was only added recently, in the v4.7
kernel.  And obviously not encrypting at all is at least as much as a
"vulnerability" as using weak encryption.  I'm also a little skeptical that
people actually care enough about big_key's for it to be worthwhile to mark a
rewrite like this for stable, though I suppose it wouldn't be *too* hard to at
least cherry-pick this to 4.9 if you wanted.  (There is a small conflict so
you'd have to send the backport yourself after this goes into mainline.)

Eric

  reply	other threads:[~2017-09-17  6:04 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-16 13:00 [PATCH v4] security/keys: rewrite all of big_key crypto Jason A. Donenfeld
2017-09-16 13:00 ` [kernel-hardening] " Jason A. Donenfeld
2017-09-16 13:00 ` Jason A. Donenfeld
2017-09-16 13:00 ` Jason A. Donenfeld
2017-09-16 13:05 ` [PATCH v5] " Jason A. Donenfeld
2017-09-16 13:05   ` [kernel-hardening] " Jason A. Donenfeld
2017-09-16 13:05   ` Jason A. Donenfeld
2017-09-16 13:05   ` Jason A. Donenfeld
2017-09-17  6:04   ` Eric Biggers [this message]
2017-09-17  6:04     ` [kernel-hardening] " Eric Biggers
2017-09-17  6:04     ` Eric Biggers
2017-09-17  6:04     ` Eric Biggers
2017-09-17 11:50     ` Jason A. Donenfeld
2017-09-17 11:50       ` [kernel-hardening] " Jason A. Donenfeld
2017-09-17 11:50       ` Jason A. Donenfeld
2017-09-17 11:50       ` Jason A. Donenfeld
2017-09-17 11:52       ` [PATCH v6] " Jason A. Donenfeld
2017-09-17 11:52         ` [kernel-hardening] " Jason A. Donenfeld
2017-09-17 11:52         ` Jason A. Donenfeld
2017-09-17 11:52         ` Jason A. Donenfeld
2017-09-20  5:30         ` Stephan Mueller
2017-09-20  5:30           ` [kernel-hardening] " Stephan Mueller
2017-09-20  5:30           ` Stephan Mueller
2017-09-20  5:30           ` Stephan Mueller
2017-09-20 10:52           ` Jason A. Donenfeld
2017-09-20 10:52             ` [kernel-hardening] " Jason A. Donenfeld
2017-09-20 10:52             ` Jason A. Donenfeld
2017-09-20 10:52             ` Jason A. Donenfeld
2017-09-20 13:45             ` Stephan Mueller
2017-09-20 13:45               ` [kernel-hardening] " Stephan Mueller
2017-09-20 13:45               ` Stephan Mueller
2017-09-20 13:45               ` Stephan Mueller
2017-09-20 14:01               ` Jason A. Donenfeld
2017-09-20 14:01                 ` [kernel-hardening] " Jason A. Donenfeld
2017-09-20 14:01                 ` Jason A. Donenfeld
2017-09-20 14:01                 ` Jason A. Donenfeld
2017-09-20 14:06                 ` Stephan Mueller
2017-09-20 14:06                   ` [kernel-hardening] " Stephan Mueller
2017-09-20 14:06                   ` Stephan Mueller
2017-09-20 14:06                   ` Stephan Mueller
2017-09-20 14:09                   ` Jason A. Donenfeld
2017-09-20 14:09                     ` [kernel-hardening] " Jason A. Donenfeld
2017-09-20 14:09                     ` Jason A. Donenfeld
2017-09-20 14:09                     ` Jason A. Donenfeld
2017-09-19 15:38       ` David Howells
2017-09-19 15:38         ` [kernel-hardening] " David Howells
2017-09-19 15:38         ` David Howells
2017-09-19 15:38         ` David Howells
2017-09-20 14:56         ` Jason A. Donenfeld
2017-09-20 14:56           ` [kernel-hardening] " Jason A. Donenfeld
2017-09-20 14:56           ` Jason A. Donenfeld
2017-09-20 14:56           ` Jason A. Donenfeld
2017-09-18  8:49 ` [PATCH v4] " Stephan Mueller
2017-09-18  8:49   ` [kernel-hardening] " Stephan Mueller
2017-09-18  8:49   ` Stephan Mueller
2017-09-18  8:49   ` Stephan Mueller
2017-09-18  9:04   ` [kernel-hardening] " Greg KH
2017-09-18  9:04     ` Greg KH
2017-09-18  9:04     ` Greg KH
2017-09-18  9:12     ` Stephan Mueller
2017-09-18  9:12       ` Stephan Mueller
2017-09-18  9:12       ` Stephan Mueller
2017-09-18 11:24   ` Jason A. Donenfeld
2017-09-18 11:24     ` [kernel-hardening] " Jason A. Donenfeld
2017-09-18 11:24     ` Jason A. Donenfeld
2017-09-18 11:24     ` Jason A. Donenfeld
2017-09-19 13:39     ` Theodore Ts'o
2017-09-19 13:39       ` [kernel-hardening] " Theodore Ts'o
2017-09-19 13:39       ` Theodore Ts'o
2017-09-19 13:39       ` Theodore Ts'o
2017-09-19 19:04       ` [kernel-hardening] " Sandy Harris
2017-09-19 19:04         ` Sandy Harris
2017-09-19 19:04         ` Sandy Harris
2017-09-19 19:17         ` Jason A. Donenfeld
2017-09-19 19:17           ` Jason A. Donenfeld
2017-09-19 19:17           ` Jason A. Donenfeld
2017-09-20  1:16         ` Theodore Ts'o
2017-09-20  1:16           ` Theodore Ts'o
2017-09-20  1:16           ` Theodore Ts'o

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=20170917060457.GB10599@zzz.localdomain \
    --to=ebiggers3@gmail.com \
    --cc=Jason@zx2c4.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=k.marinushkin@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=security@kernel.org \
    --cc=stable@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.