public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [RFC] Crypto eclass
@ 2005-05-03 20:31 Lorenzo Hernández García-Hierro
  2005-05-03 20:54 ` Simon Stelling
  0 siblings, 1 reply; 3+ messages in thread
From: Lorenzo Hernández García-Hierro @ 2005-05-03 20:31 UTC (permalink / raw
  To: gentoo-dev; +Cc: beu

Hi,

After reading and trying to work around the #88831 bug
(http://bugs.gentoo.org/show_bug.cgi?id=88831), I realized that the
automatic generation of passwords and alike is done by using just the
$RANDOM bash function, which is pretty weak (among that, wrongly used,
can cause some overhead).

I worked out a simplistic crypto.eclass that implements the following
functions:

get_random_string_seed5():
Generates a random string (33 bytes) using a simplistic seeding method
with 5 salts that uses the $RNGDEVICE (pseudo-)random numbers generator
device to gather entropy, and MD5 to calculate pseudo-random sums/hashes
to be used for calculating the final MD5 sum/hash, that is, the
(pseudo-)random string to be used finally (ie. for generating a random
password value to be used in automatically-created configuration or
installation files).
The seeds (1,2,3,4,5) are, respectively: 1000, 10, 1000, 50 & 1000 bytes
long.

get_random_string_seed1():
Same as get_random_string_seed5() but using only 1 seed.
Good if we want to avoid entropy pool exhausting in certain cases.
The only one seed is 1000 bytes long.
No parameters

get_random_string_int_md5():
Uses the $RANDOM internal Bash function that returns a pseudo-random
integer in the range 0 - 32767, used 4 times to get (usually) 19-21
bytes of pseudo random data (ie. 1626436901920922388), then generates a
MD5 sum/hash.
No parameters

get_random_string_int()
Same as get_random_string_int_md5() but not generating a MD5 sum/hash
of the obtained pseudo-random data.
No parameters

Also, any crypto-related function should get it inside such eclass
instead of placing the same code in every ebuild requiring the same or
similar operation, that is, we must reuse code as much as possible, and
providing stronger solutions, indeed.

The eclass can be found at:
http://pearls.tuxedo-es.org/gentoo/crypto.eclass

to test it, you can use:
http://pearls.tuxedo-es.org/gentoo/test-crypto-eclass.sh

Currently, the ebuilds that may benefit of this eclass directly are:

	dev-db/phpmyadmin
	net-mail/gnubiff
	sys-libs/nss-mysql
	mail-filter/dspam

There's currently a possible problem regarding collisions in the
ebuild(s):

	net-irc/irc-server

at:
	IRCUID=$RANDOM

$RANDOM can't assure that the returned integer doesn't represent an
existing uid, thus, a new function might be good to handle these cases,
that checks for existing uid before setting the value of the randomly
generated integer.

The list was provided by Elfyn (thanks!):
http://dev.gentoo.org/~beu/bash-RANDOM-utilising-ebuild.txt

Thanks in advance,
Cheers.
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>

-- 
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] [RFC] Crypto eclass
  2005-05-03 20:31 [gentoo-dev] [RFC] Crypto eclass Lorenzo Hernández García-Hierro
@ 2005-05-03 20:54 ` Simon Stelling
  2005-05-03 21:20   ` Lorenzo Hernández García-Hierro
  0 siblings, 1 reply; 3+ messages in thread
From: Simon Stelling @ 2005-05-03 20:54 UTC (permalink / raw
  To: gentoo-dev

Hi,

Lorenzo Hernández García-Hierro wrote:
> After reading and trying to work around the #88831 bug
> (http://bugs.gentoo.org/show_bug.cgi?id=88831), I realized that the
> automatic generation of passwords and alike is done by using just the
> $RANDOM bash function, which is pretty weak (among that, wrongly used,
> can cause some overhead).

Nice work, but do we really need that strong passwords? IMHO the
passwords generated by portage should be changed right after emerging
the piece of software anyway, although that might not be reality in many
cases :( I didn't have a closer look to the packages you listed, but i
hope those don't need a password for a unix account. Probably (just
guessing) they save the password in plain text anyway, so it wouldn't
matter that much...

Perhaps I'm just totally wrong.
-- 
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] [RFC] Crypto eclass
  2005-05-03 20:54 ` Simon Stelling
@ 2005-05-03 21:20   ` Lorenzo Hernández García-Hierro
  0 siblings, 0 replies; 3+ messages in thread
From: Lorenzo Hernández García-Hierro @ 2005-05-03 21:20 UTC (permalink / raw
  To: gentoo-dev; +Cc: beu

El mar, 03-05-2005 a las 22:54 +0200, Simon Stelling escribió:
> Nice work, but do we really need that strong passwords? IMHO the
> passwords generated by portage should be changed right after emerging
> the piece of software anyway, although that might not be reality in many
> cases :( I didn't have a closer look to the packages you listed, but i
> hope those don't need a password for a unix account. Probably (just
> guessing) they save the password in plain text anyway, so it wouldn't
> matter that much...
> 
> Perhaps I'm just totally wrong.

Not, but you can't ensure that users will change them, you can warn
them, you can bite them, you can kick them to do it, but they will end,
maybe, not changing the generated password.

Also, having the password in clear text has nothing to do with the
permissions that allow or restrict a certain user from accessing it,
that is, standard DAC (aka "standard Unix permissions") prevents users,
at least theoretically, from accessing those files you don't want them
to access, among that you can use MAC or any other more complex model to
enforce such access restrictions (ie. by using SELinux, RSBAC... from
Hardened Gentoo).

(Check the dev-db/phpmyadmin bug regarding the wrong permissions of the
SQL script with the password of the pma user).

As less risks we assess, less responsibilities we have to manage
regarding Q/A.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

-- 
gentoo-dev@gentoo.org mailing list


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-05-03 21:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-03 20:31 [gentoo-dev] [RFC] Crypto eclass Lorenzo Hernández García-Hierro
2005-05-03 20:54 ` Simon Stelling
2005-05-03 21:20   ` Lorenzo Hernández García-Hierro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox