river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: Security
Date Wed, 25 Feb 2015 04:28:32 GMT
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.


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

View raw message