Re: [Plastic-devs] Small plastic items

[Mark T. <m.b...@br...>]

On 14 Sep 2006, at 23:17, John Taylor wrote:

> My gut feeling is that I'd prefer to trade security for simplicity and
> assume that applications on a user's desktop are "friendly".   That

I think that's a fair assumption, where "on a user's desktop"
means "in a process owned by that user".

> said, we should make it clear to app writers what we are offering.  Can
> anyone think of something really nasty that an app could do through
> Plastic that it couldn't do already?

I've already come across a case of this.  JAC wanted a GAIA-specific
PLASTIC message which allowed PLASTIC clients to perform remote 
control.  The way this would work is to send a snippet of Tcl
code to GAIA, for GAIA to execute in its own Tcl interpreter.
This could in principle include things like "exec rm -rf *".
So you only want clients whose intentions you trust to be
able to send requests to the PLASTIC hub.  As it stands, anyone
who can make an XML-RPC or (more easily) RMI connection to the
hub can do this.  The way I solved this was to have a GAIA-specific
600 file in the user's home directory with a magic cookie in it,
which the client has to be able to read for GAIA to accept the
message.  Sending the cookie on its own is not good enough, 
since interloper applications might snoop on messages going through
the hub (using the as-yet unimplemented logging messages that
started this conversation off) and copy the cookie.  So in
fact the message arguments are (1) the Tcl script snippet and
(2) an MD5 hash of the script snippet with the cookie.  Since
third party applications (registered with the hub, but without
read access to the cookie file) never see the cookie, I think this
is reasonably secure.

Admittedly, permitting this kind of remote control is an inherently
risky thing to do.

> enough to scan for it.  So I think the best thing to do is
> a) make the .plastic file have 400 permissions

     .. and contain some kind of password which must be presented
        to the hub in order to register

> b) disallow connections from remote machines _unless they have been
> explicitly enabled_ [there are some potential uses of this, as  
> noted by Pierre].

I think that's about right, with (a) being the important one and
(b) being, well, might as well since it's fairly easy.  I'd add one 
thing, which is that each application should be given a secret key by the 
hub at registration time, which it needs to present with each message
request.  This would perform the same sort of function as the
existing client ID, but other apps would not know what it was.
This would prevent one application pretending to be another one
and, for instance, unregistering it.  I'm not really motivated 
here by serious security concerns (it would be more of an 
annoyance than anything), but it seems untidy/wrong that there's
nothing in the specification to prevent this sort of thing
happening.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b...@br... +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/