RFC: Autostart spec, first draft

[Perry Lorier]

>Snip<

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

This is why you /document/ such requirements with the "autorun" spec.

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

Sure, but the computer isn't going to do this automatically.  It's going
to do it only if the user /wants/ to execute the content.

> 3) Does not add security in any provable, obvious way.
> 
> Do you disagree with these? If so, why?

One reason that +x was required was that .desktop files can have any
icon (eg a "html document") but then can be "executed" and do something
that the user doesn't expect (not open an "html document", but become
part of a DDoS drone net).

The unix security model is based around "things that execute should be
+x".  For filesystems that don't support +x, the admin can usually
specify if all files are marked executable or not.  If the admin set the
permissions such that files are not executable by default then the admin
should be able to assume that the desktop isn't going to automatically
execute programs on that filesystem.

Sure interpreted scripts and executables /can/ be executed with
"/path/to/interpreter ./program" but that's not going to be done
automagically by the desktop environment.  If users really want to
execute content then they can.  The point is the desktop shouldn't
automatically do things behind the users back that the user isn't
expecting (executing apparently unexecutable content).

My computers usually have multiple people logged into them.  Which user
does the autorun run as?  root?  nobody?  the user logged into currently
active console?  Does it run in everyone who's logged in's session?

Does the autorun happen when the screensaver is "locked" (ie, the user
has implicitly said that they don't trust any people using their session
until their password is entered)?  Is the user who is logged in the one
that put the media in?  What if the DE isn't active when the CD is
placed in the drive? (eg, I've switched to a text console?)  Does this
change if the DE has the screensaver active or not?  Does the autorun
get to choose (I want to run as the user that has sudo access, as I'm an
installation CD that wants to install packages)?  This I think requires
the desktop environment to have telepathy to resolve.

If you can even figure out which user(s) inserted the disk and therefore
which user(s) should get the autorun launched, I still think the best
idea is to "autorun" an "index.html" file in the root of the media in a
"restricted" security context (ie, don't let javascript automatically
launch things).

I think that .desktop files should have a #! prefix on them to something
that does the actual launching which would get rid of several .desktop
problems:
* They can't be executed from the command line or shell script etc.
* It's nearly impossible to tell if the +x bit is legit in the presence
of "noexec" mounted filesystems without actually attempting to execute them.
* Programs that are saving "untrusted" information can be sure to
disallow +x being set on the file.

> Again, I ask; give us clear, obvious situations where this requirement
> would stop an attack.

I'm using a computer in a computer lab.  I go to fetch a printout of my
finished assignment, and lock my screen and leave for 5 minutes.
Another student wants a copy of my assignment so they can cheat.  They
wander up to my locked PC and plug in their usb memory stick that
contains an autorun that emails them my assignment.

A) It shouldn't automatically run as me (because it's not my usb memory
stick plugged in)
B) It shouldn't run as me because the screensaver is locked which means
I have implicitly said that any I/O from that session should be ignored
until my password is entered.
C) It shouldn't run off the FAT filesystem because the administrator has
deliberately set filesystems that don't contain +x permission flags to
not mount with files +x.
D) It shouldn't run even if the filesystem does support execute
permissions because the filesystem is mounted nosuid,noexec.

I come back to my computer, there is no longer any usb devices plugged
in, my computer is still locked and logged in as me, what evidence do I
have that my assignment has been stolen?