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