RFC: Autostart spec, first draft

[John (J5) Palmieri]

On Fri, 2005-07-08 at 10:01 +0100, Mike Hearn wrote:
> > 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?

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.

> > 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'm talking about having an autostart option and an autostart documents
option would confuse the user but having an all or nothing autostart
configuration means you have to let scripts in where documents would be
safer.  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!!!"

> I think the whole security thing here is blown way out of proportion.

Discussing security concerns in a huge concern.  Autostart in my opinion
is of little benefit and not worth pushing aside security concerns.
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 whether or not you pop up a dialog asking for confirmation (too
many users ignore warnings).  
 
> I've never heard of somebody being exploited by auto-run; can anybody 
> show me multiple examples of this? 

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

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

I am sure there are more examples.  Those are a few I came up with with
a quick google search.

> 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.

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?

> 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.

Ah, ha. This is just FUD.

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

Using this and thinking we can now go and do any number of insecure
things on the desktop in the name of "convenience" is just crazy.
Remember, convenience and security don't have to be mutually exclusive.
It may be harder to find the solution but if we go the easy route we get
burned.

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

This may not be a bad idea if it is open source but it has no bearing on
the issue at hand.

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

Your reluctance to actually discuss the issues (instead of just
attacking them) has me concerned at your ability to think security
issues out rationally.  As I had said, I don't know if the +x bit is
useful but I am willing to point out use-cases where it might be
desirable.  I have to come from a conservative view when looking at
security.  Please try to see the issue from others points of view and
then point out why you think it is a non-issue.  Don't dismiss others
concerns offhand.

-- 
John (J5) Palmieri <johnp at redhat.com>