plasma security constraints

[Chani]

for my soc project (widgets on screensaver) the appletbrowser needs to only 
offer widgets that are safe and usable on the screensaver.
in my case it's a bit of a different approach to security than normal: instead 
of trying to protect the user from bad code, I'm trying to protect them from 
strangers wandering by and messing with their computer. the aim is to offer 
widgets that can be put on the screensaver to do useful stuff, but not allow 
harmful/unexpected actions to be taken. I'm also trying to keep this flexible 
in the hope that someone else will find it useful for some other project 
someday (plasmification of kdm coomes to mind).

the way this is going to work is through a series of security constraints: an 
applet will advertise in its .desktop file which ones it can meet, and it'll 
only show up in the screensaver's appletbrowser if it satisfies all the 
constraints the screensaver has turned on. this means applets that haven't 
thought about security won't show up there by default. I've reviewed all the 
ones in workspace/plasma, kdeplasma-addons and playground and will be 
updating most of those myself.

the good news (for me) is, the vast majority of applets are either completely 
harmless, or have no business being on the screensaver ever at all. that 
means I just have to edit their desktop files and not actually code any 
security into them. :)

the tricky part is, what security constraints do we need? I've come up with an 
initial list, but I'd like some input from other people. :)

*launching external programs: this isn't entirely about security - if the 
screensaver is running, those external programs will be trapped below it, so 
that makes them rather useless. it's nice to let applets know, so that they 
can just not bother trying.

*running arbitrary commands: we have a plasmoid that allows you to just type 
in a command and run it. I don't think I have to explain why that's 
dangerous. :)

*arbitrary file read/write: this one needs splitting into several constraints, 
I think, but I'm not sure how to do it. first, should reading and writing be 
separate constraints? after that... well, filesystem access is risky. but 
there's also things like fish and ftp and so on (especially bad if ssh-agent 
is running). but I'm not sure I want to lump *all* kio protocols together, 
because one may want to allow http/https but not filesystem access.
maybe split it like this:
*local filesystem access
*remote filesystem access
*web (http/https) access
hmm, I wonder where a cd or ipod would fit in there...

*communication: sending messages using someone's identity would be bad. 
twitter on the screensaver would be better off turning read-only. whether you 
want people looking at your screensaver to be able to read incoming messages 
is your business...

*desktoppy stuff: application launchers, taskbars, systray, pager, etc... 
these only belong on a desktop, not the screensaver or anywhere else. they 
tend to assume we have a windowmanager, plasma-the-desktop, and all the usual 
stuff available. application-launchers also fall under the heading 
of "launching external programs". I need a better name for this category, 
though. :)

so, any thoughts?

oh, and a separate thing that came up while working on this: I think maybe 
X-KDE-ParentApp should be a list, not a single string. in case someone writes 
a plasmoid that, say, is useful to both amarok and the desktop.

-- 
This message brought to you by evyl bananas, and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080711/ba1c87e9/attachment.pgp