river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: another interesting link
Date Sun, 31 Jul 2016 09:20:01 GMT
Thanks Michał,

Comments inline below.

Sent from my Samsung device.
  Include original message
---- Original message ----
From: Michał Kłeczek <michal.kleczek@xpro.biz>
Sent: 31/07/2016 02:41:54 am
To: dev@river.apache.org
Subject: Re: another interesting link

 >> 2. proxy codebase jars contain a list of requested permissions to be

granted to the jar signer and url (client need not know in advance). 

This one is tricky: 
1) It is not always possible to specify fine grained permissions statically 
(for example we want to restrict the connect permission to certain hosts 
only and the hosts are only known at runtime) 
2) It is really an all or nothing approach: since we grant any permission 
that a (authenticated) service wants, we might equally grant it 

This is true, so the codebase perms should be limited to properties and other compile time
/ static concerns.  Like applets, a service proxy is granted permission by the framwork to
connect to the originatong service and codebase hosts, however if a service proxy requires
permissions to contact additional hosts, eg a database for example, it will require additional
dynamic permissions.  So there's a gap, as client configuration may not always be a suitable

As mentioned secure discovery providers I've written also dynamically grant DownloadPermission
and DeserializationPermission but only after successful authentication of the lookup service.
 I have similar mechanisms for services found in lookup results, where services are authenticated
before proxy's and Entry's are downloaded and deserialized. 

So all the above are basically codebase permissions, granted at various stages, but only as
and where necessary in order to proceed through trust establishment between client and service,
without exposing either party to DOS.

This only addresses part of the problem.


What is needed is a way to dynamically decide what permissions are granted 
to a downloaded "object". 
The word "object" is again tricky. Today permissions are granted to 
"codebases" - meaning we have no way of separating objects that share 
codebases (which is a common thing when using Maven repositories as code 

Very good point, if we separate downloading from class loading, we could separate service
instances, so they have different static fields (state) and separate identity.  To do this
will require a Maven codebase uri that contains both the codebase and server identity. This
is important, otherwise it isn't possible to tell the difference between proxy identity.

Proper separation of "trust domains" in a single virtual machine is 
difficult (and the good question is really whether it is feasible at all to 
do properly using current Java security model). 

Typically after the client is authenticated, the client’s subject is used to determine and
inject "user permissions", but only the codebase represents the server identity.

Provided sharing is minimal, such that only service api is shared, then proxy implementations
can remain private, in which case they can be separated into separate class loaders, invisible
to client or other proxy's other than via service api's. 

Of course - eliminating dynamic code downloading solves those issues - but 
I would say without dynamic code downloading there is no point in using 
River :) 

IMHO any discussions and changes that do not solve the fundamental issues 
faced when dynamically downloading code are really moot - they just mask 
the underlying problems which are going to come out sooner or later. 
And right now the architecture is fundamentally broken because of: 
- hierarchical class loaders 
- untrusted code execution (which Peter is working on) 
- not flexible enough security model 

>> 5. DownloadPermission automatically granted to authenticated registrars 
(to signer and url, very specific) during multicast discovery. 

IMHO security model should be orthogonal to any other functionality 
(service discovery being a specific example) - so any security related code 
should have absolutely no knowledge whatsoever about 
- the interfaces implemented by a particular downloaded class 
This is the reason I've avoided white listing, instead download and deserialization  permissions
are granted to the codebase uri and Signer of the codebase only.
- any network protocols used to implement discovery 
- the concept of a "discovery" 
I've managed to keep these concerns separate, security doesn't have any knowledge or responsibility
of discovery, rather disco providers request the security infrastructure to dynamically grant
the permissions required to proceed through the next stage of discovery, but only if the provider's
underlying protocol authenticates the service host
My two cents. 


Thanks for your thoughts, good to see others considering these issues.



Peter <jini@zeus.net.au> 
July 26, 2016 at 2:58 AM 
Note the comment about security on the blog? 

Steps I've taken to simplify security (that could also be adopted by river): 
1. Deprecate proxy trust, replace with authenticate service prior to 
obtaining proxy. 
2. proxy codebase jars contain a list of requested permissions to be 
granted to the jar signer and url (client need not know in advance). 
3. Policy file generation, least privilege principles (need to set up 
command line based output for admin verification of each permission during 
policy generation). 
4 Input validation for serialization. 
5. DownloadPermission automatically granted to authenticated registrars (to 
signer and url, very specific) during multicast discovery. 

Need to more work around simplification of certificate management. 


Sent from my Samsung device. 

  Include original message 
---- Original message ---- 
From: Peter <jini@zeusnet.au> <jini@zeus.net.au> 
Sent: 26/07/2016 10:27:59 am 
To: dev@river.apache.org <dev@river.apache.org> <dev@river.apache.org> 
Subject: another interesting link 


Sent from my Samsung device. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message