[Plastic-devs] Security [was Re: Small plastic items
Brought to you by:
johndavidtaylor,
thomasboch
|
From: John T. <jon...@gm...> - 2006-09-17 17:16:22
|
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 > > |