Default user decisions
On Sun, Apr 27, 2008 at 12:38:10PM +0300, Tzafrir Cohen wrote:
> On Sun, Apr 27, 2008 at 11:09:06AM +0200, Daniel Baumann wrote:
> > [should the default live user get a null password?]
>
> Password should not be required for that user in {g|k}dm (e.g: in
> case there is a need to logout and re-login). But disabling password
> elsewhere is probably not a good idea. [...] Various other optional
> packages (e.g: openssh-server) will allow remote login. I suppose it
> is a bad idea to make it password-less.
I strongly disagree. A default password is not significantly harder
to crack than a null password, and it encourages users to think "well,
it has a password, therefore it's OK to just leave it."
Furthermore, I think that if someone is going to create a live CD with
openssh-server installed by default, they (hopefully) expect that it
will be exposing an ssh service, and take the standard precautions for
such a service. (I'm assuming such services aren't installed in any
of the default builds.)
Instead of having a static, predictable, easy-to-crack password, I
would suggest taking these steps:
- give the guest user the null password, so it's very clear that it's
not secure;
- make it easy (at build time, and possibly at boot time via boot
parameters) to disable the guest user entirely. (Last time I
checked, this is merely a matter of whether 13home and a couple of
other scripts are present in live-initramfs.)
- possibly, prompt for confirmation at build time if BOTH 1) the guest
user is enabled; AND 2) any "blacklisted" packages
(e.g. openssh-server) are installed. Something like
openssh-server is to be installed, but the insecure guest user is
enabled, with a predictable username and password. Do you accept
this gaping security hole?
I'm not sure if the third point is worthwhile, since various network
layouts make different packages worthy of blacklisting. That is, the
blacklist is bound to have a bunch of false positives and negatives.
Reply to: