river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Security
Date Wed, 25 Feb 2015 12:25:28 GMT
HIP looks very promising.  Certainly solve a number of issues for River.

Jini outran the capabilities of the underlying java platform (class identity, resolution and
isolation) and underlying network protocols.

Hopefully one day these issues will be resolved.  

Cheers,

Peter.


----- Original message -----
> I think the next big thing is going to be HIP networks where Jini could
> excel as a communications platform via service discovery and the other
> parts of the platform that make it fast and easy to put together remote
> communications.
> 
> Gregg
> 
> > On Feb 21, 2015, at 9:22 PM, Peter <jini@zeus.net.au> wrote:
> > 
> > ----- Original message -----
> > > 
> > > Yes, “accidental” DOS certainly could apply, which is why I say that
> > > simple measures (like limiting the number of bytes that
> > > PreferredClassLoader will download before giving up) are a good
> > > idea.   But I think that any radical re-imagining of object
> > > serialization is outside the scope of the River project.
> > 
> > Ok, I'll bite, the work I've done doesn't fit into the radical
> > re-imagining category by any stretch, it uses the existing
> > ObjectInputStream public api and the public serial form of existing
> > objects.   It does however allow people to implement an additional
> > constructor by declaring an annotation, so they can check invariants. 
> > These invariant checks won't be performed by the standard
> > ObjectInputStream, but the classes are compatible with either.
> > 
> > My implementation also significantly outperforms java's standard
> > ObjectInputStream, reflectively calling one constructor is more
> > performant than reflectively setting every field in each class of an
> > Object's hierarchy.
> > 
> > I've decided I'll work on this on github, where interested parties can
> > participate if they want.
> > 
> > 
> > 
> > > 
> > > Cheers,
> > > 
> > > Greg Trasuk
> > > 
> > > On Feb 19, 2015, at 11:39 AM, Patricia Shanahan <pats@acm.org> wrote:
> > > 
> > > > I generally agree, but do have a question.
> > > > 
> > > > In other contexts, I've seen unintentional bugs, rather than
> > > > deliberate DOS, lead to behavior similar to DOS. A program goes
> > > > wrong, and tries to e.g. allocate far too much memory, or goes
> > > > into a loop. In contexts where that can happen, work to protect
> > > > against DOS also makes the software more robust.
> > > > 
> > > > In shared service situations, an apparently non-critical program
> > > > can cause a DOS that also affects more important programs. Either
> > > > all programs have to be designed, reviewed, and tested to the
> > > > reliability requirements of the most sensitive program with which
> > > > they share resources, or there has to be isolation between them.
> > > > 
> > > > Does this sort of consideration apply in reality to River?
> > > > 
> > > > On 2/19/2015 6:58 AM, Greg Trasuk wrote:
> > > > > 
> > > > > The type of issues you’re talking about seem to be centred on
> > > > > putting Jini services on the open internet, and allowing
> > > > > untrusted, unknown clients to access those services safely.
> > > > > 
> > > > > Personally, my interest is more along the lines of Jini’s
> > > > > original goal, which was LAN-scoped or datacenter-scoped SOA.  

> > > > > Further, I     use it on more controlled networks.     As far
as I’m
> > > > > concerned, only code that I trust gets on the network.     In a
> > > > > larger corporate scenario, I might lock down access to Reggie,
> > > > > but beyond that, I don’t consider DOS a threat.     I think it
> > > > > would make sense to be able to put a byte limit on the stream
> > > > > used to load the class, and possibly a time limit, but beyond
> > > > > that, I think you’re adding complexity that isn’t needed.   
 If
> > > > > you want to put a service on the web, use RESTful services, not
> > > > > Jini.     I’m sure there’s a discoverability tool out there,
if
> > > > > needed, but typically it isn’t.
> > > > > 
> > > > > Also, since object serialization is not specific to River, I
> > > > > wonder if there’s a better forum for these kinds of deep
> > > > > discussions.     I think it makes River look far harder than it
is.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Greg Trasuk.
> > > > > 
> > > > > On Feb 19, 2015, at 9:03 AM, Peter <jini@zeus.net.au> wrote:
> > > > > 
> > > > > > What are your thoughts on security?
> > > > > > 
> > > > > > Is it important to you?     Is it important for River?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Peter.
> > > > > 
> > > 
> > 
> 


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