[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Default user decisions

On Sun, Apr 27, 2008 at 03:00:34PM +0300, Tzafrir Cohen wrote:
> > 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]".

I'm advocating a negligible amount of extra work for the live-helper
user, not the *end* user.

> >   (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 before, I am talking about live-helper users (you), not end users
(your customers).

> 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?

Reply to: