+x bit (Was: RFC: Autostart spec, first draft)

seventh guardian seventhguardian_ at hotmail.com
Thu Jul 7 16:59:09 EEST 2005



>From: Waldo Bastian <bastian at kde.org>
>To: Mike Hearn <m.hearn at signal.qinetiq.com>
>CC: xdg at lists.freedesktop.org
>Subject: +x bit (Was: RFC: Autostart spec, first draft)
>Date: Thu, 7 Jul 2005 14:15:48 +0200
>
>On Thursday 07 July 2005 13:33, Mike Hearn wrote:
> > Waldo Bastian wrote:
> > > First draft, your feedback is highly appreciated.
> > >
> > > A desktop environment MUST NOT automatically start an application if
> > > the corresponding .desktop file has NOT been marked as executable.
> >
> > There should be some rationale for this in the spec.  Marking .desktop
> > files +x isn't especially difficult for installers, but:
> >
> > 1) Why is it necessary?
>
>In previous discussion surrounding .desktop files it was considered a 
>useful
>step to increase security (slightly). So I wanted to add it here right from
>the start.
>

I don't think this would increase the security that much, as a program that 
can put the file in place without the user knowing can also set the -x bit.


> > 2) What about noexec mounted home dirs?
>
>That's a good point. Should a user be able to execute shell code located on
>such a home dir? Is ~/.profile parsed in such a setup?
>
> > 3) For the case of auto-starting on external media eg CD-ROMs and USB
> >     Keys, they may be formatted with a filing system that does not
> >     understand the concept of the UNIX +x bit. What do people who want
> >     auto-start files in this situation do?
>
>They will need to understand the notion of "executable", no? How else would 
>a
>user be able to start an application from the media without auto-start?


Usb disks usually use the vfat filesystem, so the permissions the files get 
are the ones from the mount dir. So every file shares that -x bit, and 
there's no way of disabling it for a specific file. And usually a user that 
mounts the disk wants to be able to run files from the disk..

So if we want to implement the -x part, we first of all should agree WHY we 
wan't it (and I don't think security gets improved that much).



Also regarding autorun in removable media, we could use a desktop file in 
the media to signal that it wants to run file xx.sh or open the document 
aaa.pdf. And we would have a file in the home dir, probably in the xdg 
config dir, that would say what to do when a media device "want's" to run 
something:

On the media we could have the "Exec=" and the "Open=" keys for executables 
and documents, and on the home dir config file we would have a file with:

"AllowMediaAskExec=true/false"
"AllowMediaAskOpen=true/false"

"AllowMediaExec=true/false"
"AllowMediaOpen=true/false"

and maybe (need advice on that..):

AllowOpen[pdf]=true/false
AllowOpen[blabla]=true/false

where pdf and blabla would be the mime types..

We could also specify the default viewer for the file, but probably that's 
not necessary..

This would allow a user to auto-view a "secure" file, and to be asked for a 
non secure file (like an executable).


> > I flicked through the original thread but didn't find any discussion of
> > this requirement. As discussed previously on xdg-list, +x
> > bits/noexec-mounts do not add any real security as they are easily
> > circumvented by anybody who knows what they're doing, and for naive
> > users they just add "security through obscurity" which doesn't help much
> > either.
>
>Cheers,
>Waldo
><< attach4 >>
>_______________________________________________
>xdg mailing list
>xdg at lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/xdg

_________________________________________________________________
MSN Messenger: converse com os seus amigos online. 
http://messenger.msn.com.br




More information about the xdg mailing list