On 03/06/2017 05:19 PM, sarn wrote:
> On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
>> Excuse me if I'm asking a trivial question. Why not just seed it from
>> /dev/urandom? (or equivalent on non-Linux platforms. I know at least
>> Windows has an equivalent).
>>
>> Shachar
>
> One reason is that /dev/urandom isn't always available, e.g., in a
> chroot.  Sure, these are corner cases, but it's annoying when stuff like
> this doesn't "just work".

I don't claim to be any sort of linux expert or anything, but doesn't chroot have a reputation for being a bit of a finicky, leaky abstraction anyway? I haven't really used them, but that's been my understanding...?

On Monday, March 06, 2017 22:04:44 Nick Sabalausky  via Digitalmars-d wrote:
> On 03/06/2017 05:19 PM, sarn wrote:
> > On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
> >> Excuse me if I'm asking a trivial question. Why not just seed it from /dev/urandom? (or equivalent on non-Linux platforms. I know at least Windows has an equivalent).
> >>
> >> Shachar
> >
> > One reason is that /dev/urandom isn't always available, e.g., in a chroot.  Sure, these are corner cases, but it's annoying when stuff like this doesn't "just work".
>
> I don't claim to be any sort of linux expert or anything, but doesn't chroot have a reputation for being a bit of a finicky, leaky abstraction anyway? I haven't really used them, but that's been my understanding...?

If you want a fully secure chroot, then what you really want is BSD jails or Solaris zones. chroots are indeed too leaky to be secure. But secure container-ization doesn't really matter here, since a D program using D's standard number generator should work regardless of where it's running. So, it's a question of whether we're guaranteed to get at /dev/urandom or not, and if not, how reasonable it is to require that it be accessible for the program to run. There _are_ programs that require access to /dev, and /dev is _usually_ available.

Regardless, if there is no guarantee that /dev/urandom (or whatever system resource for getting randomness is) is going to be accessible, and we want to use it, then we either have to require that it be accessible and error out if it isn't, or we have to have a backup if accessing it fails. Ideally, you'd be able to just use /dev/urandom and not worry about it, but I don't know how common it is for /dev/urandom to be unavailable or how reasonable it is to require that it be available.

In general though, using /dev/urandom to seed the pseudo-random number generator seems like a good plan.

- Jonathan M Davis

Am Mon, 06 Mar 2017 22:04:44 -0500
schrieb "Nick Sabalausky (Abscissa)"
<SeeWebsiteToContactMe@semitwist.com>:

> On 03/06/2017 05:19 PM, sarn wrote:
> > On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
> >> Excuse me if I'm asking a trivial question. Why not just seed it from /dev/urandom? (or equivalent on non-Linux platforms. I know at least Windows has an equivalent).
> >>
> >> Shachar
> >
> > One reason is that /dev/urandom isn't always available, e.g., in a chroot.  Sure, these are corner cases, but it's annoying when stuff like this doesn't "just work".
> 
> I don't claim to be any sort of linux expert or anything, but doesn't chroot have a reputation for being a bit of a finicky, leaky abstraction anyway? I haven't really used them, but that's been my understanding...?

chroots were used for security stuff in the past (chrooting a ftp server and similar stuff) and they're indeed a leaky abstraction in that case.

However, chroots can also be used to 'chroot into another OS'. E.g. people sometimes  chroot into the OS on a harddisk from a livecd. This is sometimes useful to repair a system, install packages, ...

-- Johannes

On 07/03/17 00:19, sarn wrote:
> On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
>> Excuse me if I'm asking a trivial question. Why not just seed it from
>> /dev/urandom? (or equivalent on non-Linux platforms. I know at least
>> Windows has an equivalent).
>>
>> Shachar
>
> One reason is that /dev/urandom isn't always available, e.g., in a
> chroot.  Sure, these are corner cases, but it's annoying when stuff like
> this doesn't "just work".

If I write a program that relies on there being /dev/null, /dev/zero or /dev/tty, I don't go ahead and publish this on the program requirements. It is okay to assume those are available to me, and if your chroot/LFS install doesn't have them and my program breaks, well, tough to be you.

I don't think /dev/urandom is any different in that regard. Worst case, you can try to use it, and fall back to whatever it is we're doing today if it doesn't work. I don't think the chroot argument is a good one, though.

Shachar

On 07/03/17 09:13, Johannes Pfau wrote:
> chroots were used for security stuff in the past (chrooting a ftp
> server and similar stuff) and they're indeed a leaky abstraction in
> that case.
>

I'm not aware of an attack against a process chrooting and dropping privileges (in other words, I'm not aware of a way to escape a chroot jail unless you have root access).

Care to provide counter examples?

Thanks,
Shachar

On Tuesday, 7 March 2017 at 03:43:42 UTC, Jonathan M Davis wrote:
> On Monday, March 06, 2017 22:04:44 Nick Sabalausky  via Digitalmars-d wrote:
>> On 03/06/2017 05:19 PM, sarn wrote:
>> > On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote:
>> >> Excuse me if I'm asking a trivial question. Why not just seed it from /dev/urandom? (or equivalent on non-Linux platforms. I know at least Windows has an equivalent).
>> >>
>> >> Shachar
>> >
>> > One reason is that /dev/urandom isn't always available, e.g., in a chroot.  Sure, these are corner cases, but it's annoying when stuff like this doesn't "just work".
>>
>> I don't claim to be any sort of linux expert or anything, but doesn't chroot have a reputation for being a bit of a finicky, leaky abstraction anyway? I haven't really used them, but that's been my understanding...?
>
> If you want a fully secure chroot, then what you really want is BSD jails or Solaris zones. chroots are indeed too leaky to be secure. But secure container-ization doesn't really matter here, since a D program using D's standard number generator should work regardless of where it's running. So, it's a question of whether we're guaranteed to get at /dev/urandom or not, and if not, how reasonable it is to require that it be accessible for the program to run. There _are_ programs that require access to /dev, and /dev is _usually_ available.
>
> Regardless, if there is no guarantee that /dev/urandom (or whatever system resource for getting randomness is) is going to be accessible, and we want to use it, then we either have to require that it be accessible and error out if it isn't, or we have to have a backup if accessing it fails. Ideally, you'd be able to just use /dev/urandom and not worry about it, but I don't know how common it is for /dev/urandom to be unavailable or how reasonable it is to require that it be available.
>
> In general though, using /dev/urandom to seed the pseudo-random number generator seems like a good plan.
>
> - Jonathan M Davis

As apparently no one here hasn't mentioned this, Linux >= 3.17 has a dedicated syscall API. Please see:

http://man7.org/linux/man-pages/man2/getrandom.2.html

And this excellent introductory article:

https://lwn.net/Articles/605828

I did work on getting a nice getEntropy function into mir-random:

https://github.com/libmir/mir-random/pull/13

(For which it was planned to backport it to Phobos after some testing and real-world  feedback on the API.)

On Tuesday, 7 March 2017 at 10:18:52 UTC, Seb wrote:
> http://man7.org/linux/man-pages/man2/getrandom.2.html

>Unnecessarily reading large quantities of data will have a negative impact on other users of the /dev/random and /dev/urandom devices.  Therefore, getrandom() should not be used for Monte Carlo simulations or other programs/algorithms which are doing probabilistic sampling.

In other words it shouldn't be used when not strictly necessary.

On 03/07/2017 09:46 AM, Kagamin wrote:
> On Tuesday, 7 March 2017 at 10:18:52 UTC, Seb wrote:
>> http://man7.org/linux/man-pages/man2/getrandom.2.html
>
>> Unnecessarily reading large quantities of data will have a negative
>> impact on other users of the /dev/random and /dev/urandom devices.
>> Therefore, getrandom() should not be used for Monte Carlo simulations
>> or other programs/algorithms which are doing probabilistic sampling.
>
> In other words it shouldn't be used when not strictly necessary.

Yes, although that's true of reading /dev/(u)random too. (Just to be clear.)

On 03/07/2017 05:18 AM, Seb wrote:
>
> As apparently no one here hasn't mentioned this, Linux >= 3.17 has a
> dedicated syscall API. Please see:
>
> http://man7.org/linux/man-pages/man2/getrandom.2.html
>
> And this excellent introductory article:
>
> https://lwn.net/Articles/605828
>

Ooh, that's great to know! (Kinda sad that it seems necessary, given the "unix filesystem and unix design" ideals, but oh well, realities are realities.)

Is there a "proper" way to check for this function's existence on a local machine, other than test-compiling, or is parsing 'uname -a' as "right way" as it gets?

And anyone know about OSX? Would OSX use the getentropy the article you linked to mentions for OpenBSD? Or something else? Or just fallback to /dev/(u)random?

This really deserves a Phobos PR, IMO, FWIW. Maybe I'll try my hand at it if any OSX folk have tips for that OS.

On 2017-03-07 21:15, Nick Sabalausky (Abscissa) wrote:

> And anyone know about OSX? Would OSX use the getentropy the article you
> linked to mentions for OpenBSD?

As far as I can see, there's no "getentropy" on macOS. I see references to it online, but I cannot find it in any header files.

> Or something else?

I found something called "arc4random" and a couple of related functions [1].

> Or just fallback to /dev/(u)random?

/dev/(u)random does exist on macOS. This is what Apple seems to recommend [2].

[1] https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/arc4random.3.html

[2] https://developer.apple.com/library/content/documentation/Security/Conceptual/cryptoservices/RandomNumberGenerationAPIs/RandomNumberGenerationAPIs.html

-- 
/Jacob Carlborg