[Plastic-devs] Security [was Re: Small plastic items

[John T. <jon...@gm...>]

Hi Mark,
The solutions you propose here seem to be pretty straightforward to me.  
I agree that of two apps running on the same machine under different 
users does (at present) create a security hole.  I think I've been 
blinkered by the fact that most people will be running plastic on single 
user machines, but nevertheless there's a significant proportion of 
users that will want to run it on shared machines.   [A propos - does 
anyone know of any users that have actually done this....I know that the 
Workbench scans for a free port for the xml-rpc server....but I'm not 
certain that it does for the RMI server (clearly it should!)].

We _could_ make it clear that Plastic is not supposed to be a secure 
protocol, and discourage app writers from plastic-enabling the 
functionality you describe in GAIA without adding in their own 
security.  This seems a bit of a pity, but I'd be interested in knowing 
what other people think so I'll bring it up in Moscow and see if any 
potential plastic developers have a view.  I'd like to get a feel for 
how many developers we'd discourage with the extra complexity, versus 
how many we'll attract by the extra security!  The thing that bothers me 
is when people ask "why use Plastic, instead of messaging system X", our 
usual response is: because it doesn't try to be an all-singing 
all-dancing messaging protocol and as a result it's very simple to 
use.   Will people be wanting encryption next?  And lo! SOAP was born.

Another thing to note is that the Workbench allows far more dangerous 
access to a user's resources than any Plastic app currently does.  
That's not an excuse for us not to consider the issues, but clearly we 
need to work with Noel and whatever solutions he comes up with for the 
same issues.

A few comments on the ideas you put forward below:
1) If we implement the "cookies" as part of the API, they won't need to 
be sent as a digest since they won't be part of the regular argument 
list, so won't be logged.  On the other hand it wouldn't hurt.
2) In a way, the obfuscated xml-rpc URL already acts as a 
cookie/password - is there anything similar we could do for RMI and let 
the transport protocol take the strain?  Perhaps when Noel has finished 
reading "Java security for beginners" he can tell us.
3) If we do bring in security, then we'll have to think about how to 
make it backwards compatible with what we have now.  At some point in 
the future I see us bringing in a new API based on these PlasticRemould 
discussions, but keeping the old one around for as long as they're 
wanted.  I guess the simplest thing to do is to warn the user that an 
app is trying to connect via the old API and ask them to OK it.  
Alternatively, we could wall off the "old" API apps so they can't send 
messages to the new ones (which sounds like a recipe for user confusion 
if ever I heard one).

Apologies if this is garbled nonsense.  It was my brother's wedding last 
night, and I'm sitting in Zurich airport with something of a headache.

John



Mark Taylor wrote:
> 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
>
>