Default user decisions
On Sun, Apr 27, 2008 at 09:10:03PM +1000, Trent W. Buck wrote:
> 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."
With an empty password I would have to enable PermitEmptyPasswords in
sshd_config to actually allow someone to access the box.
>
> Furthermore, I think that if someone is going to create a live CD with
> openssh-server installed by default,
(I do. I also use ajaxterm that defaults to using 'ssh localhost' to
login)
> 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.)
(In it indeed not the default)
>
> Instead of having a static, predictable, easy-to-crack password, I
> would suggest taking these steps:
Here you assume that someone will actually bother to take action with a
live CD. Users expect it to "Just Work[tm]".
>
> - give the guest user the null password, so it's very clear that it's
> not secure;
Requires messing with sshd_config . I prefer leaving the non-empty
password. It's not that I hide it. On the default page it is clearly
written that you have to login with username 'user' and password 'live' .
>
> - make it easy (at build time,
Build time is irrelevant for me. I provide an ISO image for download.
> and possibly at boot time via boot
> parameters) to disable the guest user entirely.
This is a CD. Nobody edits the default parameters (as opposed to USB or
network boot). Nobody bothers typing extra parameters unless they really
have to. And even then, chances are they will not remember it.
> (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?
There is a pretty good chance that the user will not be at the console
more than necessary[*]. Such a propmt will needlessly stall the boot
(recall you have to do it before sshd starts)
As a rule, "asking the user" is something I hope to avoid with the live
CD. Normally such solutions are just not applicable, and the default
have to work.
>
> 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.
[*] As for "more than necessary" - what does it take to boot to the CD
automatically after a timeout of, say, 60 seconds?
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.cohen at xorcom.com
+972-50-7952406 mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
Reply to: