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 Sun, 22 Feb 2015 03:22:24 GMT
----- 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