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? _______________________________________________ debian-live-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
