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

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

On Sun, 17 Sep 2006, John Taylor wrote:

> 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 

I'm not expecting the additional burden to be high.  Maybe passing
an extra (fixed) cookie as an argument of all the method calls at
worst.

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

I certainly wasn't anticipating going as far as encryption for
normal message contents.

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

I wasn't intending sending cookies as digests - the solution I came
up with for GAIA was a bit of a special case.

> 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 

.. although it's down to the hub implementation whether/how it does
this obfuscation.  But I agree that it can in practice do the job.

> the transport protocol take the strain?  Perhaps when Noel has finished 
> reading "Java security for beginners" he can tell us.

Mark

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