linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@debian.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Debian release team <debian-release@lists.debian.org>,
	Debian kernel maintainers <debian-kernel@lists.debian.org>,
	krb5@packages.debian.org, libbsd@packages.debian.org,
	systemd@packages.debian.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: Fixing Linux getrandom() in stable
Date: Tue, 22 May 2018 22:47:02 +0300	[thread overview]
Message-ID: <20180522194702.GA2213@localhost> (raw)
In-Reply-To: <71fc1f9e921f2a755e79563903ddf676de128478.camel@decadent.org.uk>

On Mon, May 14, 2018 at 03:11:30AM +0100, Ben Hutchings wrote:
> On Sun, 2018-05-13 at 23:48 +0300, Adrian Bunk wrote:
>...
> > Due to the gdm bugs mentioned above we know that there are real-life 
> > situations where gdm currently uses "random" data that might be 
> > predictable.
> > 
> > grep tells me:
> > daemon/gdm-x-session.c:        auth_entry.data = gdm_generate_random_bytes (auth_entry.data_length, &error);
> > daemon/gdm-display-access-file.c:        *cookie = gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE,
> > 
> > Repeat the same for every package that uses /dev/urandom.
> 
> This is certain undesirable, but it's exploitable only by local users. 
> (If you let the X server listen to the network, all authentication
> cookies are sent in the clear so you've already lost.  If you use ssh X
> forwarding, it generates a new authentication cookie for use with the X
> proxy on the remote machine.)

It is possible that this specific case is not a problem.

There was a certain "never use /dev/random, /dev/urandom is always good
enough" push that started several years before getrandom() became 
available, and I'd bet someone will find exploitable cases due to
that somewhere.

The documented behaviour is that it is safe to use /dev/urandom except
during "early boot", and this is not always true in practice.

>...
> > The proper way forward might be to deprecate /dev/urandom and add a 
> > third option GRND_UNSAFE_RANDOM to getrandom() that is documented to 
> > never block but might return predictable data in some cases.
> 
> This doesn't solve anything for us.  (It does help with the original
> problem of device nodes possibly being absent from a minimal container
> or chroot.)
>...

I am less worried about device nodes possibly being absent, and more 
worried about 3 different cases splintered over 2 completely different
APIs.

Ignoring any security implications, "workaround by switching from 
getrandom() to /dev/urandom" sounds wrong since you shouldn't be
forced to a different API for that - getrandom() is what people
should use, therefore it should offer all 3 options.

> Ben.
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

      reply	other threads:[~2018-05-22 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <75577b3d2efd01aaf563f1a1400a2c655556b258.camel@decadent.org.uk>
2018-05-13 20:48 ` Fixing Linux getrandom() in stable Adrian Bunk
2018-05-13 21:23   ` Thorsten Glaser
2018-05-14  0:30     ` Theodore Y. Ts'o
2018-05-14  0:50       ` Thorsten Glaser
2018-05-14 13:05     ` Sam Hartman
2018-05-14  2:11   ` Ben Hutchings
2018-05-22 19:47     ` Adrian Bunk [this message]

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=20180522194702.GA2213@localhost \
    --to=bunk@debian.org \
    --cc=ben@decadent.org.uk \
    --cc=debian-kernel@lists.debian.org \
    --cc=debian-release@lists.debian.org \
    --cc=krb5@packages.debian.org \
    --cc=libbsd@packages.debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=systemd@packages.debian.org \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).