Bug#411552: please set a timeout in syslinux screen
On Tue, Feb 20, 2007 at 03:35:30AM -0500, Joey Hess wrote:
> Here are some scenarios to consider:
>
> * Suppose that I'm blind. I put in the CD, reboot, and wait the 5
> minutes I generally wait to get it past post[1]. Then I carefully start
> typing the necessary kernel options for my braille reader into the
> syslinux prompt I expect to be there...
syslinux supports beeping (by printing ^G or with the .beep command specified
in menu/MENU_FORMAT). If d-i beeps (once or even a few times) when the boot
prompt is presented, that helps a lot. If it beeps a few seconds before the
time runs out, that also helps.
I think this makes it even better than what we have now (since user doesn't
really know if she waited enough or not). But of course, input from a blind
person on this would be more interesting.
> * Suppose that the machine is being booted by a rack monkey at the data
> center. If it's set up like my data center, this means they put the CD
> in the front of the rack, power on the machine, then run 200 feet
> around to the back of the rack -- only to find that the crash cart
> with the display isn't hooked up to the right machine. So they switch
> it to the right one. Meanwhile, I want them to boot with "auto=true" to
> avoid walking them through the whole install over the phone, and am
> subsequently quite confused when I tell them to type that, and they
> say that it replies with "Elektu landon, teritorion au aeron" and some
> other strange words.
>
> Can you figure out what happened based on the above description? :-)
Well, not really. Typing "auto\n" enables Tagalog, and "<foo> auto=true\n"
enables English. But I get the point ;)
How big is that datacenter anyway? I can't imagine your "monkey" being so
slow not to be back there in 5 minutes. Anyway, we can make the timeout
even longer.. and for a long enough timeout, the benefit of supporting some
more computers should outgrow the inconvenient of having a timeout at all.
> * My grandnephew Kai Runyon[2] is here visiting. He's 2, and he likes to
> pound on keyboards and flip switches. He finds my power switch. Then he
> finds my keyboard. I come out of a programming haze to find my media
> server formatting its home directory thanks to the d-i CD I just had
> it burn.
>
> Ok, granted, the timeout only saved him one well-placed enter, but
> it's not unheard of for my home network to have preseed setups enabled
> that let this whole scenario happen with only a few keystrokes.
That's very bad security if you don't trust people with local access (even
if they're not malicious ;)). I take it you use your media server to burn
preseed setups but never to *test* them, so shouldn't your media server
have CD boot disabled in BIOS?
> * My kiosk machine only has a user-accessible touchscreen, the keyboard
> is locked away to avoid all those easily implantable keylogger chips,
> and other problems. I leave an installation CD in it so that it can be
> quickly reinstalled if something goes wrong, or weekly (just in case).
> One day I decide to switch it to this new version of the lenny CD,
> which happens to be the one where g-i becomes the default installer.
> This also happens to be the one that a tricky user of the kiosk uses to
> intercept a lot of credit card numbers, after running through the whole
> g-i install using only the keypad, to get root.
Bad security again. Shouldn't these machines have anything-but-first-hard-disk
boot disabled in BIOS? And if you enable that temporarily and then leave a CD
that gives anyone root, and rely exclussively on lack of keyboard *and* d-i
not having any timeout for a system where security is so critical that it
can be used to steal credit card numbers, I think you get what you deserve.
> [2] Hi future Kai doing your first self-google! :-)
Lol. Maybe google won't exist by then ;)
--
Robert Millan
My spam trap is honeypot@aybabtu.com. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.
Reply to: