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