Generating random.seed for network boot clients

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Generating random.seed for network boot clients

Clint Pachl
Is it safe to generate some randomness in /tftpboot/etc/random.seed for
clients that PXE boot?

My concern is that this file will be available to everyone on the
network via TFTP. So does knowing this randomness help "predict" the
PRNG output of the clients that use it?

I read in a de Raadt interview earlier this year that there are other
sources mixed in at the boot loader state. So I'm guessing it shouldn't
hurt, but probably help. Some clarification on the subject from an
expert would be greatly appreciated.

Thanks,
Clint

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Paul de Weerd
On Fri, Aug 15, 2014 at 01:24:02AM -0700, Clint Pachl wrote:
| Is it safe to generate some randomness in /tftpboot/etc/random.seed for
| clients that PXE boot?
|
| My concern is that this file will be available to everyone on the network
| via TFTP. So does knowing this randomness help "predict" the PRNG output of
| the clients that use it?

What you could do is use the -r option to tftpd(8) to hand out a new
file to each client that connects.  Or just periodically (like, every
hour or every minute, depending on the load of your tftp server)
replace it with a new random file.

| I read in a de Raadt interview earlier this year that there are other
| sources mixed in at the boot loader state. So I'm guessing it shouldn't
| hurt, but probably help. Some clarification on the subject from an expert
| would be greatly appreciated.

I have an /etc/random.seed in my tftp server.  I don't do any of the
above, since I *very* seldomly do PXE boots, and when I do I need to
update kernel and bootloader anyway, so I've automated updating
random.seed by adding it into the script that picks bsd.rd+pxeboot for
a selected architecture.

Note that the transfer is in clear text.  So even if you change it, it
could be intercepted during transfer depending on your network setup.

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Theo de Raadt
In reply to this post by Clint Pachl
> Is it safe to generate some randomness in /tftpboot/etc/random.seed for
> clients that PXE boot?

I do not even know if that file will be read... is it?

> My concern is that this file will be available to everyone on the
> network via TFTP. So does knowing this randomness help "predict" the
> PRNG output of the clients that use it?

It isn't worse.  It won't hurt.

> I read in a de Raadt interview earlier this year that there are other
> sources mixed in at the boot loader state. So I'm guessing it shouldn't
> hurt, but probably help. Some clarification on the subject from an
> expert would be greatly appreciated.

Yes, other things are mixed in as well.

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Paul de Weerd
On Fri, Aug 15, 2014 at 06:04:56AM -0600, Theo de Raadt wrote:
| > Is it safe to generate some randomness in /tftpboot/etc/random.seed for
| > clients that PXE boot?
|
| I do not even know if that file will be read... is it?

Yes, it is.  Twice, in fact:

Aug 15 14:13:34 tuna tftpd[14711]: 192.168.34.110: read request for 'pxeboot'
Aug 15 14:13:34 tuna tftpd[14711]: 192.168.34.110: read request for 'pxeboot'
Aug 15 14:13:34 tuna tftpd[14711]: 192.168.34.110: read request for '/etc/boot.conf'
Aug 15 14:13:39 tuna tftpd[14711]: 192.168.34.110: read request for '/etc/random.seed'
Aug 15 14:13:40 tuna tftpd[14711]: 192.168.34.110: read request for '/etc/random.seed'
Aug 15 14:13:40 tuna tftpd[14711]: 192.168.34.110: read request for 'bsd.rd'

Not sure why the file is hit twice, hadn't noticed it before.

Cheers,

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Christian Weisgerber
In reply to this post by Theo de Raadt
On 2014-08-15, Theo de Raadt <[hidden email]> wrote:

>> Is it safe to generate some randomness in /tftpboot/etc/random.seed for
>> clients that PXE boot?
>
> I do not even know if that file will be read... is it?

I would hope so since pxeboot complains about its absence:

>> OpenBSD/amd64 PXEBOOT 3.23
boot>
cannot open tftp:/etc/random.seed: No such file or directory

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Alexander Hall
In reply to this post by Theo de Raadt
On August 15, 2014 2:04:56 PM CEST, Theo de Raadt <[hidden email]> wrote:
>> Is it safe to generate some randomness in /tftpboot/etc/random.seed
>for
>> clients that PXE boot?
>
>I do not even know if that file will be read... is it?

IIRC, it is tried but deemed unsafe (0555) and therefore isn't used, but causes a warning. Maybe it had changed since.

/Alexander

>
>> My concern is that this file will be available to everyone on the
>> network via TFTP. So does knowing this randomness help "predict" the
>> PRNG output of the clients that use it?
>
>It isn't worse.  It won't hurt.
>
>> I read in a de Raadt interview earlier this year that there are other
>
>> sources mixed in at the boot loader state. So I'm guessing it
>shouldn't
>> hurt, but probably help. Some clarification on the subject from an
>> expert would be greatly appreciated.
>
>Yes, other things are mixed in as well.

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Paul de Weerd
On Fri, Aug 15, 2014 at 04:07:21PM +0200, Alexander Hall wrote:
| On August 15, 2014 2:04:56 PM CEST, Theo de Raadt <[hidden email]> wrote:
| >> Is it safe to generate some randomness in /tftpboot/etc/random.seed
| >for
| >> clients that PXE boot?
| >
| >I do not even know if that file will be read... is it?
|
| IIRC, it is tried but deemed unsafe (0555) and therefore isn't used, but causes a warning. Maybe it had changed since.

What do you mean?  You don't get permissions with a TFTP transfer.  If
the tftpd can read the file, it'll send it to you.  If it can't, it
won't (surprise, surprise ;).

Paul 'WEiRD' de Weerd

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Alexander Hall
On 08/15/14 16:22, Paul de Weerd wrote:

> On Fri, Aug 15, 2014 at 04:07:21PM +0200, Alexander Hall wrote:
> | On August 15, 2014 2:04:56 PM CEST, Theo de Raadt <[hidden email]> wrote:
> | >> Is it safe to generate some randomness in /tftpboot/etc/random.seed
> | >for
> | >> clients that PXE boot?
> | >
> | >I do not even know if that file will be read... is it?
> |
> | IIRC, it is tried but deemed unsafe (0555) and therefore isn't used, but causes a warning. Maybe it had changed since.
>
> What do you mean?  You don't get permissions with a TFTP transfer.  If
> the tftpd can read the file, it'll send it to you.  If it can't, it
> won't (surprise, surprise ;).

 From sys/lib/libsa/tftp.c:

...
int
tftp_stat(struct open_file *f, struct stat *sb)
{
        struct tftp_handle *tftpfile;
        tftpfile = (struct tftp_handle *) f->f_fsdata;

        sb->st_mode = 0444;
...

Ok, it wasn't 0555, but 0444. Close enough.

Then, in sys/stand/boot/boot.c:

...
void
loadrandom(char *name, char *buf, size_t buflen)
{
...
        if (fstat(fd, &sb) == -1 ||
            sb.st_uid != 0 ||
            (sb.st_mode & (S_IWOTH|S_IROTH)))
                goto fail;
...

So, actually, if the file exists, it will not emit a warning (like it
does if it's non-existent), but silently ignore it. :-)

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Paul de Weerd
On Fri, Aug 15, 2014 at 06:55:49PM +0200, Alexander Hall wrote:
| On 08/15/14 16:22, Paul de Weerd wrote:
| >On Fri, Aug 15, 2014 at 04:07:21PM +0200, Alexander Hall wrote:
| >| On August 15, 2014 2:04:56 PM CEST, Theo de Raadt <[hidden email]> wrote:
| >| >> Is it safe to generate some randomness in /tftpboot/etc/random.seed
| >| >for
| >| >> clients that PXE boot?
| >| >
| >| >I do not even know if that file will be read... is it?
| >|
| >| IIRC, it is tried but deemed unsafe (0555) and therefore isn't used, but causes a warning. Maybe it had changed since.
| >
| >What do you mean?  You don't get permissions with a TFTP transfer.  If
| >the tftpd can read the file, it'll send it to you.  If it can't, it
| >won't (surprise, surprise ;).

Ah, I see what you mean.  All files transferred via tftp are
considered to have 0444 permissions by the requesting process (quite a
sane approach) and therefore not accepted (not so sure about that part
in this case).

I'm guessing the reasoning not to trust world writable files is to
prevent attackers from putting with known contents into the mix.  I'm
not sure if that's any worse than not having anything at all (and the
contents of that buffer thereby being predictable, perhaps?  not even
sure whether that's true...)

At any rate, this changes that to allow world readable files (still
not taking world writable files).  We can't check S_IWOTH over tftp,
we should probably assume 0777 for files transferred that way.  But,
if you're trusting the kernel you're getting over tftp, then why the
hell are you not trusting random.seed?  That attacker that could maybe
influence your randomness would NEVER touch your kernel to ensure it
only produces well known (to them) randomness.  That would be way too
easy...

Note that this diff doesn't fix the repeated attempts at loading the
seed file.  Still don't grok what's going on there.

Index: boot.c
===================================================================
RCS file: /cvs/src/sys/stand/boot/boot.c,v
retrieving revision 1.43
diff -u -p -r1.43 boot.c
--- boot.c 19 Feb 2014 22:02:15 -0000 1.43
+++ boot.c 15 Aug 2014 21:41:01 -0000
@@ -153,7 +153,7 @@ loadrandom(char *name, char *buf, size_t
  }
  if (fstat(fd, &sb) == -1 ||
     sb.st_uid != 0 ||
-    (sb.st_mode & (S_IWOTH|S_IROTH)))
+    (sb.st_mode & (S_IWOTH)))
  goto fail;
  (void) read(fd, buf, buflen);
 fail:

| From sys/lib/libsa/tftp.c:
|
| ...
| int
| tftp_stat(struct open_file *f, struct stat *sb)
| {
| struct tftp_handle *tftpfile;
| tftpfile = (struct tftp_handle *) f->f_fsdata;
|
| sb->st_mode = 0444;
| ...
|
| Ok, it wasn't 0555, but 0444. Close enough.
|
| Then, in sys/stand/boot/boot.c:
|
| ...
| void
| loadrandom(char *name, char *buf, size_t buflen)
| {
| ...
| if (fstat(fd, &sb) == -1 ||
|    sb.st_uid != 0 ||
|    (sb.st_mode & (S_IWOTH|S_IROTH)))
| goto fail;
| ...
|
| So, actually, if the file exists, it will not emit a warning (like it does
| if it's non-existent), but silently ignore it. :-)
|
| /Alexander
|

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Paul de Weerd
On Fri, Aug 15, 2014 at 11:51:53PM +0200, Paul de Weerd wrote:
| At any rate, this changes that to allow world readable files (still
| not taking world writable files).  We can't check S_IWOTH over tftp,
| we should probably assume 0777 for files transferred that way.  But,
| if you're trusting the kernel you're getting over tftp, then why the
| hell are you not trusting random.seed?  That attacker that could maybe
| influence your randomness would NEVER touch your kernel to ensure it
| only produces well known (to them) randomness.  That would be way too
| easy...

Actually, no, scratch that.  You don't want the local seed to be world
readable, since that will expose it to everybody on the local system
for non-TFTP loaded kernels and seedfiles.

The alternative then is to assume 0440 for files transferred from
tftp.  The permissions on files transferred from tftp are irrelevant
following the above argument (you trust that kernel you just
downloaded, might aswell trust random.seed).  To make random.seed pass
the loadrandom() tests, just set st_mode to 0440:

Index: tftp.c
===================================================================
RCS file: /cvs/src/sys/lib/libsa/tftp.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 tftp.c
--- tftp.c 13 Jul 2014 15:31:20 -0000 1.6
+++ tftp.c 15 Aug 2014 22:03:27 -0000
@@ -386,7 +386,7 @@ tftp_stat(struct open_file *f, struct st
  struct tftp_handle *tftpfile;
  tftpfile = (struct tftp_handle *) f->f_fsdata;
 
- sb->st_mode = 0444;
+ sb->st_mode = 0440;
  sb->st_nlink = 1;
  sb->st_uid = 0;
  sb->st_gid = 0;

--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
                 http://www.weirdnet.nl/                 

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Christian Weisgerber
In reply to this post by Paul de Weerd
On 2014-08-15, Paul de Weerd <[hidden email]> wrote:

> What you could do is use the -r option to tftpd(8) to hand out a new
> file to each client that connects.  Or just periodically (like, every
> hour or every minute, depending on the load of your tftp server)
> replace it with a new random file.

How about making etc/random.seed a named pipe and feeding chunks
of /dev/random to it?  Something like

# cd /tftpboot
# mkfifo etc/random.seed
# while true; do dd if=/dev/random count=1 >etc/random.seed 2>/dev/null; done &

seems to work at first blush.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Alexander Hall
In reply to this post by Paul de Weerd
On August 15, 2014 11:51:53 PM CEST, Paul de Weerd <[hidden email]> wrote:

>On Fri, Aug 15, 2014 at 06:55:49PM +0200, Alexander Hall wrote:
>| On 08/15/14 16:22, Paul de Weerd wrote:
>| >On Fri, Aug 15, 2014 at 04:07:21PM +0200, Alexander Hall wrote:
>| >| On August 15, 2014 2:04:56 PM CEST, Theo de Raadt
><[hidden email]> wrote:
>| >| >> Is it safe to generate some randomness in
>/tftpboot/etc/random.seed
>| >| >for
>| >| >> clients that PXE boot?
>| >| >
>| >| >I do not even know if that file will be read... is it?
>| >|
>| >| IIRC, it is tried but deemed unsafe (0555) and therefore isn't
>used, but causes a warning. Maybe it had changed since.
>| >
>| >What do you mean?  You don't get permissions with a TFTP transfer.
>If
>| >the tftpd can read the file, it'll send it to you.  If it can't, it
>| >won't (surprise, surprise ;).
>
>Ah, I see what you mean.  All files transferred via tftp are
>considered to have 0444 permissions by the requesting process (quite a
>sane approach) and therefore not accepted (not so sure about that part
>in this case).
>
>I'm guessing the reasoning not to trust world writable files is to
>prevent attackers from putting with known contents into the mix.  I'm
>not sure if that's any worse than not having anything at all (and the
>contents of that buffer thereby being predictable, perhaps?  not even
>sure whether that's true...)
>
>At any rate, this changes that to allow world readable files (still
>not taking world writable files).  We can't check S_IWOTH over tftp,
>we should probably assume 0777 for files transferred that way.  But,
>if you're trusting the kernel you're getting over tftp, then why the
>hell are you not trusting random.seed?  That attacker that could maybe
>influence your randomness would NEVER touch your kernel to ensure it
>only produces well known (to them) randomness.  That would be way too
>easy...
>
>Note that this diff doesn't fix the repeated attempts at loading the
>seed file.  Still don't grok what's going on there.

I

Please remember that this change isn't limited to tftp, but affects all potential ways we fetch the seed. Either way, I think it's safe enough, and I'm all for this change, so ok halex@ unless someone finds an obvious flaw.

/Alexander

>
>Index: boot.c
>===================================================================
>RCS file: /cvs/src/sys/stand/boot/boot.c,v
>retrieving revision 1.43
>diff -u -p -r1.43 boot.c
>--- boot.c 19 Feb 2014 22:02:15 -0000 1.43
>+++ boot.c 15 Aug 2014 21:41:01 -0000
>@@ -153,7 +153,7 @@ loadrandom(char *name, char *buf, size_t
> }
> if (fstat(fd, &sb) == -1 ||
>    sb.st_uid != 0 ||
>-    (sb.st_mode & (S_IWOTH|S_IROTH)))
>+    (sb.st_mode & (S_IWOTH)))
> goto fail;
> (void) read(fd, buf, buflen);
> fail:
>
>| From sys/lib/libsa/tftp.c:
>|
>| ...
>| int
>| tftp_stat(struct open_file *f, struct stat *sb)
>| {
>| struct tftp_handle *tftpfile;
>| tftpfile = (struct tftp_handle *) f->f_fsdata;
>|
>| sb->st_mode = 0444;
>| ...
>|
>| Ok, it wasn't 0555, but 0444. Close enough.
>|
>| Then, in sys/stand/boot/boot.c:
>|
>| ...
>| void
>| loadrandom(char *name, char *buf, size_t buflen)
>| {
>| ...
>| if (fstat(fd, &sb) == -1 ||
>|    sb.st_uid != 0 ||
>|    (sb.st_mode & (S_IWOTH|S_IROTH)))
>| goto fail;
>| ...
>|
>| So, actually, if the file exists, it will not emit a warning (like it
>does
>| if it's non-existent), but silently ignore it. :-)
>|
>| /Alexander
>|

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Alexander Hall
In reply to this post by Paul de Weerd
On August 16, 2014 12:09:32 AM CEST, Paul de Weerd <[hidden email]> wrote:

>On Fri, Aug 15, 2014 at 11:51:53PM +0200, Paul de Weerd wrote:
>| At any rate, this changes that to allow world readable files (still
>| not taking world writable files).  We can't check S_IWOTH over tftp,
>| we should probably assume 0777 for files transferred that way.  But,
>| if you're trusting the kernel you're getting over tftp, then why the
>| hell are you not trusting random.seed?  That attacker that could
>maybe
>| influence your randomness would NEVER touch your kernel to ensure it
>| only produces well known (to them) randomness.  That would be way too
>| easy...
>
>Actually, no, scratch that.  You don't want the local seed to be world
>readable, since that will expose it to everybody on the local system
>for non-TFTP loaded kernels and seedfiles.

Well, it is merely added to the mix, and only once, so I don't think it adds any substantial attack vector.

>
>The alternative then is to assume 0440 for files transferred from
>tftp.  The permissions on files transferred from tftp are irrelevant

I think that just feels strange.

>following the above argument (you trust that kernel you just
>downloaded, might aswell trust random.seed).  To make random.seed pass
>the loadrandom() tests, just set st_mode to 0440:
>
>Index: tftp.c
>===================================================================
>RCS file: /cvs/src/sys/lib/libsa/tftp.c,v
>retrieving revision 1.6
>diff -u -p -u -r1.6 tftp.c
>--- tftp.c 13 Jul 2014 15:31:20 -0000 1.6
>+++ tftp.c 15 Aug 2014 22:03:27 -0000
>@@ -386,7 +386,7 @@ tftp_stat(struct open_file *f, struct st
> struct tftp_handle *tftpfile;
> tftpfile = (struct tftp_handle *) f->f_fsdata;
>
>- sb->st_mode = 0444;
>+ sb->st_mode = 0440;
> sb->st_nlink = 1;
> sb->st_uid = 0;
> sb->st_gid = 0;

I'd be fine with someone ok'ing that, but it won't be me. :)

At the very least, and maybe either way, we should print a warning if we decide not to use the file because of loose permissions.

/Alexander

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Clint Pachl
In reply to this post by Paul de Weerd
Paul de Weerd wrote, On 08/15/14 14:51:
> At any rate, this changes that to allow world readable files (still
> not taking world writable files).  We can't check S_IWOTH over tftp,
> we should probably assume 0777 for files transferred that way.  But,
> if you're trusting the kernel you're getting over tftp, then why the
> hell are you not trusting random.seed?  That attacker that could maybe
> influence your randomness would NEVER touch your kernel to ensure it
> only produces well known (to them) randomness.  That would be way too
> easy...

Good point.


> Index: boot.c
> ===================================================================
> RCS file: /cvs/src/sys/stand/boot/boot.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 boot.c
> --- boot.c 19 Feb 2014 22:02:15 -0000 1.43
> +++ boot.c 15 Aug 2014 21:41:01 -0000
> @@ -153,7 +153,7 @@ loadrandom(char *name, char *buf, size_t
>   }
>   if (fstat(fd, &sb) == -1 ||
>      sb.st_uid != 0 ||
> -    (sb.st_mode & (S_IWOTH|S_IROTH)))
> +    (sb.st_mode & (S_IWOTH)))
>   goto fail;
>   (void) read(fd, buf, buflen);
>   fail:

Nonetheless, on a generally secure internal network it's a benefit to
have this the extra random source. But if it doesn't exist or it is
known to the world, like Theo previously said, "it isn't worse."

The only downside is if the random.seed was used in a compromise of the
PRNG of the client (not sure if that's possible). But then I guess I
revert to Paul's point above.

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Clint Pachl
In reply to this post by Christian Weisgerber
Christian Weisgerber wrote, On 08/15/14 18:36:

> On 2014-08-15, Paul de Weerd <[hidden email]> wrote:
>
>> What you could do is use the -r option to tftpd(8) to hand out a new
>> file to each client that connects.  Or just periodically (like, every
>> hour or every minute, depending on the load of your tftp server)
>> replace it with a new random file.
> How about making etc/random.seed a named pipe and feeding chunks
> of /dev/random to it?  Something like
>
> # cd /tftpboot
> # mkfifo etc/random.seed
> # while true; do dd if=/dev/random count=1 >etc/random.seed 2>/dev/null; done &
>
> seems to work at first blush.

I liked de Weerd's idea using the -r option with tftpd. I was thinking I
could use a socket to signal a small script containing nc(1) for the
domain socket communication. The script would detect if the requested
file was "etc/random.seed", and if so, refresh the randomness, otherwise
just pass the original request file back (essentially a NOP). Then tftpd
would serve up this freshly generated randomness on a per request basis.

But shit, Christian's one-liner above works like a charm!

I was skeptical at first, but after some testing I'm convinced that it
works great with tftpd(8).

# cd /tftpboot
# mkfifo test.seed
# while :; do dd if=/tmp/counter of=test.seed 2>/dev/null; done &

# cnt=0
# cd /tmp

# echo $((cnt++)) > counter
# echo "get test.seed\nquit" | tftp localhost
# cat test.seed
0

# echo $((cnt++)) > counter
# echo "get test.seed\nquit" | tftp localhost
# cat test.seed
1

# echo $((cnt++)) > counter
# echo "get test.seed\nquit" | tftp localhost
# cat test.seed
2

# ###DON'T UPDATE COUNTER### echo $((cnt++)) > counter
# echo "get test.seed\nquit" | tftp localhost
# cat test.seed
2

and you get the picture ...

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Christian Weisgerber
On 2014-08-16, Clint Pachl <[hidden email]> wrote:

>> # cd /tftpboot
>> # mkfifo etc/random.seed
>> # while true; do dd if=/dev/random count=1 >etc/random.seed 2>/dev/null; done &
>
> # cd /tftpboot
> # mkfifo test.seed
> # while :; do dd if=/tmp/counter of=test.seed 2>/dev/null; done &

Careful!

"dd ... >fifo" (O_WRONLY) blocks until there is a reader.

By contrast, "dd ... of=fifo" (O_RDWR) does not block and if you
run it in a loop, you'll end up with a busy loop.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Christian Weisgerber
In reply to this post by Christian Weisgerber
On 2014-08-16, Christian Weisgerber <[hidden email]> wrote:

> How about making etc/random.seed a named pipe and feeding chunks
> of /dev/random to it?

I've now put this into my /etc/rc.local:

------------------->
# Provide fresh random.seed for pxeboot

if cd /tftpboot/etc; then
        rm -f random.seed
        mkfifo random.seed
        # do not fill up filesystem if the FIFO disappears
        # dd of= does not block on open
        sh -c 'while [ -p random.seed ]; do dd count=1 >random.seed; done' \
            </dev/random 2>/dev/null &
fi
<-------------------

* It blocks until random.seed is read.
* It doesn't run amok if random.seed is accidentally removed.
* It's easy to identify with ps(1).

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Theo de Raadt
In reply to this post by Clint Pachl
I wonder if there would be some benefit to faking these files from inside
the tftp daemon itself..

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Brent Cook
This is starting to remind me of Ubuntu's pollen/pollinate services.


On Sat, Aug 16, 2014 at 11:31 AM, Theo de Raadt <[hidden email]>
wrote:

> I wonder if there would be some benefit to faking these files from inside
> the tftp daemon itself..

Reply | Threaded
Open this post in threaded view
|

Re: Generating random.seed for network boot clients

Clint Pachl
In reply to this post by Christian Weisgerber
Christian Weisgerber wrote, On 08/16/14 08:54:

> On 2014-08-16, Christian Weisgerber <[hidden email]> wrote:
>
>> How about making etc/random.seed a named pipe and feeding chunks
>> of /dev/random to it?
> I've now put this into my /etc/rc.local:
>
> ------------------->
> # Provide fresh random.seed for pxeboot
>
> if cd /tftpboot/etc; then
>          rm -f random.seed
>          mkfifo random.seed
>          # do not fill up filesystem if the FIFO disappears
>          # dd of= does not block on open
>          sh -c 'while [ -p random.seed ]; do dd count=1 >random.seed; done' \
>              </dev/random 2>/dev/null &
> fi
> <-------------------
>
> * It blocks until random.seed is read.
> * It doesn't run amok if random.seed is accidentally removed.
> * It's easy to identify with ps(1).

Very nice. It seems like this might be a good addition to /etc/rc
because the OS depends on it. It's not like it's system, site, or
application specific.

Anyway, thanks everyone for all the feedback on this subject.

12