RFC: Autostart spec, first draft
m.hearn at signal.QinetiQ.com
Fri Jul 8 12:01:20 EEST 2005
> 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
More information about the xdg