Mike Hearn wrote:
[...]
Right now Linux is in the same situation, you could make an app auto-start
by abusing:
- session management
- various $HOME dotfiles (.xsession, .profile ?)
- gnome/kde specific mechanisms for this
- and now this spec
[...]
Frameworks like SELinux or AppArmor can help prevent this - if only a
certain program, say /usr/bin/register-autostart can write to
~/.config/autostart and no other programs run with regular user privs can,
then this register-autostart program can pop up a GUI saying "Do you
really want $XYZ program to auto-start? Yes/No" giving users a chance to
veto this request. OK it may not help /much/ but it might help a bit.
Hmm, this would only work if you use SE-Linux and would only prevent one
way for applications to auto-start when there are dozens other ways to
achieve the same effect (you missed hacking the StartMenus, the Desktop
icons, XDG/Mailcap/KDE/Gnome MIME associations, hacking $PATH, etc).
This seems akin to upgrading ssh to a stronger encryption algorithm
while leaving the root account with no password: the ssh upgrade does
not improve overall security at all.
It may be possible to play nice tricks with SE-Linux but to be effective
these would really need to lock out way more than just
~/.config/autostart, and they should be able to work without cooperation
from the underlying standard (because Mailcap is obviously not going to
be changed at this late stage).
> Obviously if an app is installed as root via RPM or whatever then it's
> game over.
It's worse than that. As soon as you run any untrusted piece of code,
even in your account, it is game over for your account.
--
Francois Gouget
[EMAIL PROTECTED]
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
