+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