Re: [Plastic-devs] Small plastic items

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

Mark Taylor wrote:
> On Thu, 14 Sep 2006, Alasdair Allan wrote:
>
>   
>> Mark Taylor wrote:
>>     
>>> Longer term, I'd like to see hub implementations supporting a  
>>> message or messages which is/are sent (to anyone who's asked)  
>>> logging all traffic.  This would be able to provide more  
>>> information, including who messages have been sent to and what the  
>>> responses were.
>>>       
>> Of course at this point we wander into the wonderful world of  
>> authentication and security. If I direct a message to a specific  
>> application via the hub, rather than a broadcast message to all  
>> applications supporting that message, should the hub be permitted to  
>> pass the existence of that message on to a 3rd party logging  
>> application?
>>     
>
> That is a good point.  Maybe the best thing to do there is to arrange 
> that by default the hub will not publicise potentially private message
> content, but that it can be configured to do so (for debugging
> purposes etc).  If you're being paranoid you shouldn't send 
> sensitive content in the first place, since there's nothing in
> PLASTIC which says that the hub is not allowed to do this,
> and precedent in V0.4 for it doing so.  There are various 
> other security issues, some of which I can think of fixes for 
> (e.g. see sec. 6 of
>
>    http://wiki.eurovotech.org/twiki/bin/view/VOTech/PlasticRemould
>
> ), but I doubt we're ever going to be in a position to introduce an
> ivo://votech.org/pay(String creditCardNum, int pin, float amount)
> message.
>   
Certainly, Plastic is pretty insecure at the moment.  I think we 
probably need to think carefully before trying to make it completely 
secure....its selling point is that it's simple, and we don't want to 
complicate it with extra baggage unless we have to.  If we want an all 
purpose messaging system then perhaps we should pick one off the shelf. 

As noted on

http://wiki.eurovotech.org/twiki/bin/view/VOTech/PlasticRemould

there is a danger that some script kiddie could take control of your hub 
remotely.  Even if we did randomise the RMI port, it would be easy 
enough to scan for it.  So I think the best thing to do is
a) make the .plastic file have 400 permissions
b) disallow connections from remote machines _unless they have been 
explicitly enabled_ [there are some potential uses of this, as noted by 
Pierre].

Point a) should give the user some limited protection against other 
users on the same machine.


I don't have a problem with needing to explicitly enable the logging 
feature - it's probably only us dev types that are going to want it 
anyway, and it doesn't complicate the spec.  I do wonder whether we need 
to worry ourselves too much though....is it really likely that GAIA will 
snoop on messages to Aladin, and rebroadcast them with corrupted 
arguments to try to steal market share ;-) !

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

John