RFC: Autostart spec, first draft

[Mike Hearn]

> That is not the use-case I described.  What I described was a user
> downloading something and then just putting it into their autostart
> folder.  Or perhaps just downloading it to their autostart folder.
> Either way I did say I'm not sure if it is useful or not thought it is
> worth the time to debate it.

Oh yes, I agree it's worth debating, I'm just arguing that it doesn't 
add any security so it shouldn't be in the spec.

Experience tells me that this sort of thing is very easy to forget; I've 
seen quite a few packages and installers (including my own) mysteriously 
fail to register icons because people forgot to touch the root theme 
directory. Not saying that's a bad requirement of the icon spec: it 
makes sense in that situation. But it's a source of bugs, so let's not 
require this sort of extra step unless there's a really good reason.

 > Having to hold down the shift key seems stupid to me.  How do I
> know if I do or don't want something autostarted?  "Oh there's an
> autostart script with rm -rf ~/, quick hold down the shift key!!!"

That comes back to the more general issue of trust, which I think is out 
of scope for this spec. How does the user know whether to trust 
something? It's a hard question. Suffice it to say, by the time they 
chose to insert it into their computer, or install it from a package, 
they have chosen to trust it. Putting extra requirements on the 
shoulders of developers dosen't do anything except make bugs more likely.

> Discussing security concerns in a huge concern.  Autostart in my opinion
> is of little benefit and not worth pushing aside security concerns.

Ah, well, this is where we disagree :) Having worked tech support 
before, I think it's a huge benefit, and I can't see any security 
concerns at all from it. That's why there is debate here.

> Don't be so quick to brush them aside.  Having arbitrary code start on
> ones machine by simply popping in a disk or USB key is a huge security
> concern 

This seems to be a specific form of the "allowing the user to add 
code/data to their system is security concern" idea. Yes, it is, but 
it's also what makes computers useful so we can't get away from it.

> http://www.net-security.org/article.php?id=745 talks about autorun as a
> security concern.

I didn't listen to the whole thing but he seems to be discussing a 
theoretical risk, not something that ever happened.

> http://technology.updates.com/clickthru.aspx?typeid=32&siteid=2&storyid=80209&topicid=13 an actual autorun virus

No, it's not a "virus" despite the Registers atrocious reporting. Go 
read the report; it's actually an anti-piracy device. The "virus" in 
question was put there by the CD publishers and is designed to stop 
people ripping the CD. That's not a virus by any definition of the word, 
it's normally called a driver.

> People trust many things.  It is no reason to not look at the security
> implications.  We protect the system from what the user "trusts", why
> not try to protect the user?

This is a philosophical point - we shouldn't make the user jump through 
arbitrary hoops to make the computer do what they want because it's 
*their* computer. We can advise them, sure. We can warn them, sure. We 
can implement virus filtering and quarantining to help them protect 
themselves, but making things hard on the assumption that users are 
stupid and shouldn't be trusted with control of the device they paid for 
is silly.

> Ah, ha. This is just FUD.

Why is it FUD? Imagine Fedora (or any Linux distribution actually, I 
never saw any that did automatic online updates out of the box) and 
Windows XP had equal market share: 50/50.

Exploits will be found for both, this is certain. Windows users need do 
nothing to receive patches, Linux users must manually run "yum 
upgrade"/"apt-get upgrade" etc, or in the best case scenario click on a 
system tray icon. But as the pre-SP2 Windows experience showed, users do 
not do this in large numbers. Out of the box it should be automatic: 
this change increased Windows security in a visible, measurable way.

Given the massive importance of security patches in keeping hackers and 
viruses at bay, I think you could credibly argue that even despite 
exec-shield and SELinux, Windows XP SP2+ is more secure than Fedora.

But anyway, we drifted off topic :) My point is that this is focussing 
on minutae where there's no evidence of improvement, when we could be 
making big differences elsewhere.

> Your reluctance to actually discuss the issues (instead of just
> attacking them) has me concerned at your ability to think security
> issues out rationally.  

There has been lots of discussion - I've said that requiring the +x bit:

1) Adds a source of bugs from people who will inevitably forget, or not
    realise, and then spend ages trying to figure out why it's not
    working. I've been there, done that with menus and icons, and it'd be
    nice to keep things intuitive and easy in future.

2) Has obscure semantics w.r.t noexec mounts, which aren't really noexec
    anyway because you can still run scripts from such mounts and anybody
    could write a scripted ELF interpreter in Perl, which then means you
    can run ELF binaries too.

3) Does not add security in any provable, obvious way.

Do you disagree with these? If so, why?

So far, I've not seen any clear reasons why requiring it increases 
security. Only some vague ideas that requiring user interaction will 
make things more secure, or that maybe if you could force a file to 
appear in some location yet not be able to set metadata it might work 
... but nobody figured out how to do that yet.

Again, I ask; give us clear, obvious situations where this requirement 
would stop an attack.

thanks -mike