On Sat, Jan 06, 2001 at 11:51:18PM -0600, robert bonomi wrote:
> > I don't know how select() would act on a regular file. /dev/random
> > (and/or /dev/urandom) are no regular files, so we could first call
> > stat() and only continue when S_ISCHR() is true (character device).
>
> In the environments where I'm intimately familiar with this behavior,
> to wit SunOS 4.x, and a couple of BSD 4.x derivations -- nn a regular
> file, select() gets immediate/continuous "data ready to be read", until
> such time as EOF is reached. Whereupon it gets EOF indication -once-.
> Something else appending to the file (*after* EOF has been detected)
> does *NOT* result in a subsequent 'data ready' response.
That makes perfect sense. Otherwise one would even block on
cat /var/adm/syslog/syslog.log
as syslogd has it open all the time :-)
> > Hmm, I would consider using non-blocking reads. Select() does not know
> > how many bytes you intend to read, so it will return "available" if
> > just one byte is there and the second byte will block. Of course we could
> > read byte-per-byte...
> > So we can stay with non-blocking reads, try to take the minimum defined
> > (20bytes as of now) and just take what's there.
>
> A far superior approach. With the caveat that if you don't get all that
> you want the first time, you _do_ need to loop, until you get a 'would block'
> indication. I've seen some _awfully_ dumb 'virtual device' implememntations
The question is whether we want to wait or not. With respect to Richard's
proposal I would say it makes sense to wait once for (20ms or whatever),
then we might try another source (we are currently discussing addition of
other automatically accessed sources).
> > magically find it. This location would need to be in a "safe" place, so
> > that no normal user can fake one just handing back prepared information
> > (ruling out /tmp as proposed in the egd-documentation). The only place
> > would probably in /etc. I know that /var would be better (I have my sockets
> > /under /var/run), but the directory structure is not portable enough.
> > -> /etc/egd-socket?
> > (I would not use /dev as this is for device files only (and might lead
> > to trouble on Linux-2.4 not even having a real /dev directory).)
>
> At a minimum, I'd request an 'environment variable' over-ride. Yeah, this
> is in direct contrast to your 'need to be in a "safe" place' comment.
That is one of the "yes and no" points. I vaguely remember some vulnerability
on securityfocus last week that had to do with environment controlled
loading of shared libraries (we have some work left before 0.9.7, BTW :-).
It affected suid programs and the solution was to check real and effective
uid or so. If we want environment variables in effect, we have to add
additional security measures... I actually think the OpenSSL _library_
should stay away from it. Using environment variables should be left for
applications..
> I run some systems where /etc is on (hardware-level) Read-Only media. Can't
> create sockets there, obviously. The only writable space is under /home,
> /var, and /tmp. Sockets and named pipes end up under /var, mostly -- a few
> are in sub-directories under /tmp.
That's a point. I also would prefer a place in /var, but it must be a
place where not everybody can create a socket... It is up to us do define one!
> Whatever the 'place' is, it's going to need to be major OS-type specific.
> What is meaningful for UNIX isn't likely to be so for VMS, the MS world
> is a whole 'nother kettle of fish. Without mention of some of the weirder
> environments.
Agreed. -> e_os.h
> Suggest maybe a 'list' of 'typical places to look', followed by a series
> of 'sanity checks' (ownership, etc.) on anything that's found. Including
> checking/following symlinks. Comment: if owner is a "system" account,
> -or- matches either the real or effective UID of the running code, one
> probably wants to let it pass. This allows for the possibility that a
> user, for their own purposes, might deliberately _want_ to have *their*own*
> instance of the program using a 'predictable' random number sequence.
> While preventing anybody from suberting "somebody else's" use of the
> random device.
Then this "somebody" will have to recompile OpenSSL anyway. Due to the
bad advice given on openssl-* in the past people have introduce the
"practice" to seed the prng with a static string. To prevent that, OpenSSL
starting with 0.9.6 will always try to query /dev/urandom to get entropy in
any case!
> The real "wish-list" approach would be to have a _configuration-time_
> utility that sniffs out the random device(s), and passes appropriate
> info to the compilation process.
I don't think this is a good idea, as it enforces recompilation on
installation of a new entropy source. Since (except for total failure of
seeding) no diagnostic output is given, you may run with weak seeding
without noting e.g. in case you move from /var/run/egd-pool to
/var/spool/egd/socket because this looks more elegant and forget to recompile.
Let's rather add a list of places and have this static; stop on success.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
