RFC: Autostart spec, first draft

[Mike Hearn]

> In the case of the autostart script +x is important.  Why would you be
> running a script from a FAT drive in the first place?

As Kevin said, running apps from USB keys is increasingly common. 
Likewise, it may be in future that USB mass storage based MP3 players 
and such will include auto-start programs so you get a nice 
guide/welcome on the screen when you plug it in. Who knows what kind of 
storage systems we'll be using in future?

> We do it with evolution where any downloaded file is marked as
> non-executable.  The user has to explicitly set the execute bit if it is
> an executable.  It is just another layer of security to make sure the
> user doesn't just double click and run a trojan.  

I remain entirely unconvinced of the merits of this. The problem is that 
the user *does not receive any more information* by being forced to make 
something +x. If they have decided to run a program, having to toggle an 
obscure checkbox somewhere won't change their mind at all, except maybe 
making them think "Linux sucks, why does it get in my way like this?".

If people actually are saving attachments to disk and clicking them 
without meaning to then maybe we need to revise the concept of the mouse 
rather than introduce more "Just Doesn't Work" hurdles.

For the perhaps more common case of the user thinking a program is one 
thing when really it's another, you need to be bundling and enabling 
ClamAV in distributions to solve that. The user isn't going to suddenly 
realise something is a trojan because they had to tick a "I know what 
I'm doing" box.

> It would be an extra
> layer of security to avoid someone from just dropping any old file they
> downloaded into the autostart directory.  Not saying if this is useful
> but that would be the use-case. 

If they can drop a file into the autostart directory then they can 
almost certainly modify its metadata as well. Why are we increasing 
complexity of a spec, adding more gotchas people will inevitably forget 
and then spend hours debugging, for no measurable gain in security?

Can people actually provide examples of how you would be able to put 
something in the autostart directory without the user knowing but not be 
able to simultaneously control its permissions?

> Hmm, but configuration would get hard for this.  Is it worth the
> confusion to the user?  Plus there are still security concerns such as
> media file exploits.

Configuration? Why does it need configuration - Windows lets you disable 
it on a case-by-case basis by holding down the shift key.

I think the whole security thing here is blown way out of proportion. 
I've never heard of somebody being exploited by auto-run; can anybody 
show me multiple examples of this? By definition, if something is 
auto-run from mountable media the user inserted it into their computer 
which means they already made the decision to trust the contents.

If you really want to solve some low-hanging Linux security fruit:

a) Get online updates automatically downloaded and installed on Fedora.
    Right now Windows XP SP2 out of the box is atomically more secure
    than Fedora is, simply because users don't have to remember to
    download and install updates which is 99% of what stopping hacking
    and viruses is about.

b) Bundle and integrate a virus scanner like ClamAV into the desktop
    so users are less likely to be hit by random trojans

c) Bundle and integrate the Netcraft anti-phishing toolbar into
    the Fedora firefox build.

Combined those would do way more for security than anything +x bit 
related would.

thanks -mike