[Security-sig] PEP 524: Make os.urandom() blocking on Linux (version 3)

[Nick Coghlan]

On 30 July 2016 at 00:30, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2016-07-29 15:31 GMT+02:00 Barry Warsaw <barry at python.org>:
> According to the size of the discussion, I consider that it's worth it
> to use a PEP to add os.getrandom(). Exposing getrandom() was proposed
> in different ways which was also part of the discussion.
>
> The fact that getrandom() is directly exposed or not has a major
> impact on the overall PEP.
>
> For example, I don't think that it's worth to add os.getrandom() if
> the PEP 522 is implemented. The PEP 522 directly gives access to
> non-blocking system urandom, so os.getrandom(GRNG_NONBLOCK) is useless
> (it's less portable and more complex to use, see my other email in
> this thread). The remaining question is if it is woth to expose
> os.getrandom(GRNG_RANDOM) ... PEP 522 and PEP 524 advice to avoid
> /dev/random which should really be reserved for a very limited number
> of application. These applications can already open manually
> /dev/random, code which would work on all Python versions!
>
> Finally, only adding os.getrandom() was also proposed as the complete
> solution to "the bug": users are expected to move slowly to this new
> function. Nick explained it:
> https://www.python.org/dev/peps/pep-0522/#why-propose-this-now
>
> So I don't consider that it's tiny detail in the discussion...

Right, to elaborate on my point of view a bit further, I'm not
entirely happy with the current design in PEP 522, as it doesn't
offer:

- a way of accessing the system level blocking behaviour on Linux (you
have to emulate it with a loop)
- a way to directly transcribe getrandom() based code to or from C on
modern Linux or Solaris

So adding os.getrandom() doesn't necessarily have anything to do with
fixing people's code, and instead has to do with providing access to
the corresponding kernel capability on platforms that provide it -it's
a "What is the os module for?" argument rather than a "How do we
encourage good security programming practices?" argument. It also
isn't something that can be readily provided via cffi or ctypes, as
glibc doesn't offer an API for it yet - you have to call the syscall
directly, which I believe is possible via cffi/ctypes, but presumably
tough to make robust against platform variations.

PEPs 522 and 524 then become a matter of posing the question, "Given
the existence of os.getrandom(), how do we fix currently at risk uses
of the os.urandom() function?":

* tell people to use os.getrandom() if available, os.urandom()
otherwise (both PEPs rejected)
* make them fail noisily, with a cross-platform way to opt-in to
blocking (PEP 522)
* make them "just work" in most cases, but potentially block in some
situations (PEP 524)

So what I'll probably do is update PEP 522 to assume os.getrandom()
will be available (with the above rationale), and then see how that
changes the rest of the PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia