Ague Mill:
> On Mon, Oct 15, 2012 at 02:47:05PM +0000, Abel Luck wrote:
>> intrigeri:
>>> Hi,
>>>
>>> Jacob Appelbaum wrote (13 Oct 2012 11:02:17 GMT) :
>>>> As this is a modular kernel - is there a reason not to simply add
>>>> a "enable firewire" widget?
>>>
>>> There are several I can see:
>>>
>>> * It is a UX failure every time someone has to go out of their way to
>>> have Tails work with their hardware.
>>> * Every such widget we add to Tails Greeter makes the greeter worse
>>> for every Tails user: more cluttered, more complicated.
>>>
>>> That's why I still prefer the "let's guess what the user wants"
>>> approach: if they plug a device in the "X" slot, that's probably
>>> because they want to use it, so let's keep the "X" bus enabled, and
>>> disable it else.
>>>
>>> OTOH, I understand your concern, and I now think the 5 minutes delay
>>> that was suggested may be a bit too long. We did not specify exactly
>>> when the 5 minutes countdown starts, anyway. Perhaps we could start an
>>> initscript right after GDM, have it sleep 1 minute, and then disable
>>> these dangerous buses if unused? (This gives a clear visual indication
>>> of when the countdown starts.)
>>
>> Regardless of the solution proposed above, would it be possible to have
>> an alternate grub menu that disables these dangerous interfaces from the
>> get go?
>
> Please note that Tails is using SYSLINUX at the moment and not GRUB.
Noted.
>
>> There could be an "Advanced" grub menu entry, that displays these
>> alternative kernel-param boot options.
>>
>> Surely, there should be *some* secure option where the window of attack
>> is zero?
>
> How would you label it so that it does not puzzle users who are using a
> FireWire external disks, but never had to think about the word "FireWire"
> before?
Sorry, I wasn't clear. The bootime options I proposed were the firewire
disabled options.
Assuming, as seems to be the reasoning so far, that the default behavior
will be the most usable (enabled for X minutes then disabled, or w/e),
my idea is to have a "disabled from boot" alternative option.
To answer your question, my thought was it would be hidden behind an
advanced menu, so users who didn't care and didn't know will not pay it
any mind.
Example (for the sake of clarity):
+----------------+
| |
| * Boot Tails |
| * Memtester |
| * Advanced > | <----- option behind this menu
| |
+----------------+
>
> What would you write in the end-user documentation? Who would be using
> such option?
>
The documentation would explain, in layman's terms, the risk of such
interfaces, then it would explain the default behavior of the X-minute
window. Next, it would explain the the potential threat scenarios in
which a user might be concerned about that window, and, finally,
instruct how to use the advanced option.
I would use such an option, I imagine Jake would as well (though I won't
speak for him). Any potential tails user (1) with the awareness of such
attacks and (2) desire mitigate them.
> I am afraid about the endless stream of "why are you not making it the
> default?", like the one we already get regarding Javascript. Answers
> would probably be even quite similar. I'm not having such option, but it
> really needs to be done right.
>
Absolutely it should be done right.
You shouldn't be afraid of that question. The answer to "why are you not
making it the default?" is being discussed right now in this email
thread, see Jacob's point in the great-great-grandfather of this message
and intrigeri's reply.
I still think this should be the default, and the enabled firewire the
advanced option. I can't imagine the majority of users use firewire.
Putting the majority at risk for the minority doesn't seem a good idea,
BUT I can concede that thought with the 1-minute window proposal.
Nevertheless, my point (repeating myself here), is that there should be
a zero-second window option regardless, for those that care. Moreover,
that option does not have to significantly affect the UX.
~abel
