plasma security constraints

[Aaron J. Seigo]

On Friday 11 July 2008, Chani wrote:
> *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.

we'll also want this for certain lock down scenarios, such as untrustred 
downloaded scripts ...

> *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. :)

how is this differentiated from "launching external programs"? is there a 
situation where it would be Ok to launch arbitrary UI apps but not system 
commands?

> *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

yes, with read/write for each.

> hmm, I wonder where a cd or ipod would fit in there...

unmounting/mounting volumes? (e.g. via Solid)

> *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...

right; so there's a general "untrusted individual" category

we shoul also be able to generate the above in an aumated fashion for QScript 
based applets. (the other languages are less hopeful as they contain a lot 
more builtins and the ScriptEngine authors for those languages don't have much 
focus on this aspect of script driven applets)

> *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. :)

you can probably filter on the applet category here; Windows and Tasks, 
Application Launchers.

> 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.

X-KDE-ParentApp is already defined elsewhere and as used elsewhere actually 
makes sense as a single string. so we probably need something slightly 
different in plasma to augment this.

perhaps use X-KDE-ParentApp to say "this comes from Amarok" and X-
Plasma-{SOMETHING} to say "it's also useful outside of Amarok"?

as for the appletbrowser, it seems it will need to:

* allow defining allowable applet categories
* allow definition of a security profile
* allow defining not just the host app, but also if other apps are 
supported/desired?

i'd like to avoid going all the way with "define a constraint in 
KServiceTypeTrader syntax" ..

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080713/0fa78e71/attachment.pgp