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: