RFC: Autostart spec, first draft

[seventh guardian]

>From: Mike Hearn <m.hearn at signal.QinetiQ.com>
>To: "John (J5) Palmieri" <johnp at redhat.com>
>CC: xdg at lists.freedesktop.org, Waldo Bastian <bastian at kde.org>
>Subject: Re: RFC: Autostart spec, first draft
>Date: Fri, 08 Jul 2005 10:01:20 +0100
>
>>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.
>

Also, disabling -x for downloaded files ONLY works if we download binary 
files (executables). If we download a tar.gz file, then the contents would 
still be executable. Also, we could download that tar.gz, and we usually put 
it in the home dir, right? So, if we untar it there a trojan could be 
easilly placed in our autorun dir, without us even knowing (and marked as 
executable!!!).

So it definitelly doesn't do more than making our lives more complex.

This security issue could be solved if there was somekind of registry file, 
where an autorun file needed to be registered, and that could be the task of 
the dm. Even so, there's also the possibility of exploiting some thing like 
this.

So the only way of really making things secure is having as few  files to 
config as possible, so that the user could check them once in a while.. or 
check them after running some "strange" program. Simple things tend to break 
less frequently.


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

Well, you know me! Back when I used windows I almost got a virus from a limp 
bizkit cd. It's "media content" was infected, but fortunatelly I had an 
updated anti-virus running.

Still, I probably would run it if I didn't knew, because I wanted to see a 
video that was on it.

On the other hand, if I had autorun off, I could easilly go and open the 
video file without passing through the infected app.


>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
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg

_________________________________________________________________
MSN Busca: fácil, rápido, direto ao ponto.  http://search.msn.com.br