Set pre-encrypted passwords for users

[Axel Freyn]

Hi Cristian,
On Wed, Mar 31, 2010 at 01:08:19PM +0100, Joel Merrick wrote:
> On Wed, Mar 31, 2010 at 12:21 PM, Cristian Ionescu-Idbohrn
> <cristian.ionescu-idbohrn at axis.com> wrote:
> > On Wed, 31 Mar 2010, Joel Merrick wrote:
> >
> >> Use useradd or usermod
> >>
> >> ie..
> >>
> >> useradd -o -s /bin/bash -p $ENCPASS user
> >
> > But that will make $ENCPASS visible with:
> >
> >        $ tr '\0' ' ' < /proc/PID/cmdline
> >
> > for a moment.  Isn't reading from a file descriptor is the prefered
> > method for doing that?
> >
[Well, I didn't follow the complete discussion, but...]

Is that really a problem, if the ENCRYPTED password can be read? For
sure, one reason for /etc/shadow is to prevent exactly that, but during a
FAI-installation, I see much more serious ѕecurity concerns (well: if
you don't trust the network during the installations...):

1) when booting from the network: The install client can't guarantee
   that it is connected to the true DHCP/tftp - Server (except you can
   use the switches to block all other DHCP and tftp-traffic...). So an
   attacker with a local root-account somewhere in the LAN can fake
   everything.

2) during installation, FAI uses NFSv3 for the running operating system.
   Again: this can be faked / read-out ==> an attacker could gain
   root-access to the system running during the installation - and with
   that he can do everything on the running machine. Or (as nfs3 is not
   encrypted...) he can just read /etc/shadow to learn the encrypted
   root-password used during installation;-).

3) When reading the config-space: only svn+ssh would be secure
   (assuming, that during the first install the ssh-Key has been
   verified by another means (e.g. the sys-admin...)). The default (?)
   NFSv3 is unprotected; an attacker can:
   - fake it (and supply wrong install-data including passwords to the
     client)
   - read it (and with that: read all (encrypted) passwords stored there
     (e.g. the root-password as it is treated in the simple examples)

4) When using network-booting and tftp, the simple examples change after
   the installation the boot-configuration on the tftp-Server (by
   WRITING into the tftp-server-directory). As soon as you allow that,
   everybody in the local network has write-access to the configuration
   files in the tftp-server - an thus can also tell the machines to load
   another kernel from another tftp-server, etc. 


I'm quite sure there are much more problems like that... Of course, it
is possible to avoid all of them - by a clean & secure configuration, or
by only doing FAI-installations while only trusted computers are
connected to the network, or by connecting the install-clients to a
private VLAN during installation or something similar. But at least my
opinion is: a possible access (during a few seconds) to an encrypted
password is much less dangerous than those examples...

And a last point: If you are not planning to create users during a
soft-update, there is an easy solution to the problem: 
 - first, use "useradd" to add the users - but always lock the account.
   Then, nobody except "root" can login to the machine - and nobody can
   read the passwords (except root - but if an attacker already has the
   root-account, you are lost....)
 - second, loop over all users and activate the accounts - now, no
   passwords are needed - and thus it is impossible to read the
   encrypted passwords from /proc/PID/cmdline


Axel
root-accou