river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: another interesting link
Date Sat, 30 Jul 2016 16:41:54 GMT
 >> 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
"AllPermission"

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

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

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
- any network protocols used to implement discovery
- the concept of a "discovery"

My two cents.

Thanks,
Michal

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.

Regards,

Peter.
Sent from my Samsung device.

  Include original message
---- Original message ----
From: Peter <jini@zeus.net.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

https://blogs.oracle.com/hinkmond/entry/jini_iot_edition_connecting_the


Sent from my Samsung device.

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