river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: WELCOME to dev@river.apache.org
Date Sat, 06 Oct 2012 01:01:32 GMT
Hi Bishnu,

Sorry for the slow reply, River is maintained by volunteers, we don't 
have as much time as we'd like.  Your service browser is interesting.

There are significant challenges with security, River (Jini) has 
constraints, which allow clients and services to require integrity, 
confidentiality and minimum server or client principals.  You may find 
constraints very useful, these could be supported in your browsers 
security settings.

JERI has superceded RMI in Jini, it's the standard for exporting service 
objects and allows an administrator to select from pluggable Exporters 
that use different protocols, including RMI, IIOP, TLS etc.  JERI is 
required for constraints.

During object serialization there is a window of time where objects are 
created and class loading occurs, prior to a ProtectionDomain 
representing them being pushed onto the execution stack, allowing an 
attacker to take advantage of privileges the current execution stack 
has, this is the mechanism for java deserialisation privilege escalation 
attacks reported recently by popular media.  To avoid this 
vulnerability, permissions must be minimised during deserialisation.  

JAAS in its standard implementation, injects Principals into all 
ProtectionDomain on the call stack (which must have sufficient privilege 
for it to occur). ProtectionDomains added to the stack after login and 
Subject.doAs, are not injected, but may be subject to deserialisation 
attacks if and when local code is privileged.  A user login adds 
permission to existing ProtectionDomains, which may all be privileged in 
any case.  I've proposed for distributed environments that this 
behaviour be changed so a ProtectionDomain representing the Subject be 
pushed onto the stack instead, allowing a user to have a different alias 
for browsing untrusted networks, where the user has restricted 
permission to prevent deserialisation privilege escallation attacks on 
client or server jvm's, even when the jvm or application code would 
otherwise be vulnerable.  This could be supported as a list of 
permissions the user has selected for the alias on clients, or by being 
granted a particular principal on servers.  This would greatly simplify 
configuring java permissions.

Deserialisation is still subject to denial of service (out of memory 
error or stack overflow), however this is only of inconvenience value, 
the jvm can be easily killed and restarted.

Trust in a community is based on identity and observed behaviour.

SPKI has an interesting authorisation delegation model, allowing users 
to remain anonymous while avoiding the need for Certificate 
Authorities.  An example use case: a company delegates authority to 
access external resources to its employees with short term tickets; 
certificates that expire daily.  A company or household may hold a 
contract with a supplier for a resource, this may expire on monthly or 
annual contract terms, during login, resources may be allocated on a 
daily basis by creating a certificate chain that delegates permission, 
every time a user logs in.

org.apache.river.api.security.PermissionGrant is a stateless abstract 
class (originally designed as an interface, enforcing security was 
complex, so an abstract class was chosen instead) that would also allow 
standard java Permissions to be granted and expire.  There is a 
DelegatePermission framework (implementation to be distributed 
separately) and caching DelegateSecurityManager that for example, 
enables Li Gong's method guard pattern to be applied to existing Socket 
implementations using a SocketFactory wrapper.

Which reminds me; I need to create a directory on svn for the delegates 

These things are low level, what is needed is a simplifying upper layer 
that makes using services in the service browser simple and secure.

To achieve goals you've set in the paper, there's plenty of work left to do.

Best Regards,


Bishnu Gautam wrote:
> Hi
> No, I am not using ServiceUI, instead, I have written myself that exports the wrapped
services to the client. We can still export the very light weight browser as jini service
too. In that way, we can still make our jini services that can run in client machine. I am
calling this browser as Universal Browser.  I have written a paper about this scenario more
in detail at following paper:
> http://www.iaeng.org/publication/IMECS2010/IMECS2010_pp638-643.pdf 
> You may find number of services running in the browser including web browser. Yes, this
is the right time how we can make good service interface that can be used by client at end.
> RegardsBishnu
> Bishnu Prasad Gautam
>> Date: Tue, 4 Sep 2012 08:12:24 +0100
>> Subject: Re: WELCOME to dev@river.apache.org
>> From: dan.creswell@gmail.com
>> To: dev@river.apache.org
>> Can you say a little more about the JPanel wrapping? Are you making use of
>> ServiceUI or custom generating something or ?
>> The reason I'm asking is because for client-side exposure of graphical
>> material, a browser is a good place to go especially with the arrival of
>> HTML5. In fact, perhaps it's time we re-evaluated ServiceUI...
>> On 4 September 2012 01:26, Bishnu Gautam <bishnu35@hotmail.com> wrote:
>>> Hi Peter and Simon
>>> Thanks for messages.Yes, I was thinking of DNS-SRV discovery. Also, UDT is
>>> better than TCP. I am very interested to use Java UDT and totally agree to
>>> apply this protocol. That will efficiently work I think. I am building an
>>> application that transfer all bundled JPanel wraped jini/river services to
>>> client sides. I am able to execute it in muliti-Lan environment. I will
>>> donate this code to river community. My next phase is to implement it to
>>> execute in internet. If you guys have already implemented some of it, lets
>>> share the codes or lets discuss so that we can bring river project as one
>>> of the demanding solution not only in distributed environment but also for
>>> the cloud community. I think this is the right time for jini/river
>>> community to come into the business or into the cloud.
>>> RegardsBishnu
>>> Bishnu Prasad Gautam
>>>> Date: Mon, 3 Sep 2012 18:12:55 +1000
>>>> From: jini@zeus.net.au
>>>> To: dev@river.apache.org
>>>> Subject: Re: WELCOME to dev@river.apache.org
>>>> Thanks Bishnu, welcome to River!
>>>> I've had some plans with regard to internet based services, not much
>>>> implemented I'm afraid, time constraints...
>>>>    1. org.apache.river.api.lookup.StreamServiceRegistrar - interface for
>>>>       internet based service registrars (lookup service).
>>>>    2. DNS-SRV Discovery, to use in place of multicast discovery, this
>>>>       (not yet implemented) discovers the location of lookup services,
>>>>       to be used in Unicast Discovery.
>>>>    3. Java UDT Sockets - not yet implemented, this is basically Data
>>>>       over UDP, which is easier to get through firewalls than TCP.
>>>> Regards,
>>>> Peter.
>>>> Bishnu Gautam wrote:
>>>>> Hello River Team
>>>>> It seems that Jini is getting its pace in terms of River. This is good
>>> indication and I think that River has great potential if we can build some
>>> application that can interact over Internet.I am planning to do a research
>>> work whether we can make an application of River that can interact over
>>> internet as I found there are some issues of firewall etc. Would you let me
>>> know, whether the River team has plan of bringing River on the Internet ?
>>>>> Bishnu Prasad Gautam
>>>>>> Date: Sun, 2 Sep 2012 00:48:45 +0000
>>>>>> From: dev-help@river.apache.org
>>>>>> To: bishnu35@hotmail.com
>>>>>> Subject: WELCOME to dev@river.apache.org
>>>>>> Hi! This is the ezmlm program. I'm managing the
>>>>>> dev@river.apache.org mailing list.
>>>>>> I'm working for my owner, who can be reached
>>>>>> at dev-owner@river.apache.org.
>>>>>> Acknowledgment: I have added the address
>>>>>>    bishnu35@hotmail.com
>>>>>> to the dev mailing list.
>>>>>> Welcome to dev@river.apache.org!
>>>>>> Please save this message so that you know the address you are
>>>>>> subscribed under, in case you later want to unsubscribe or change
>>>>>> subscription address.
>>>>>> --- Administrative commands for the dev list ---
>>>>>> I can handle administrative requests automatically. Please
>>>>>> do not send them to the list address! Instead, send
>>>>>> your message to the correct command address:
>>>>>> To subscribe to the list, send a message to:
>>>>>>    <dev-subscribe@river.apache.org>
>>>>>> To remove your address from the list, send a message to:
>>>>>>    <dev-unsubscribe@river.apache.org>
>>>>>> Send mail to the following for info and FAQ for this list:
>>>>>>    <dev-info@river.apache.org>
>>>>>>    <dev-faq@river.apache.org>
>>>>>> Similar addresses exist for the digest list:
>>>>>>    <dev-digest-subscribe@river.apache.org>
>>>>>>    <dev-digest-unsubscribe@river.apache.org>
>>>>>> To get messages 123 through 145 (a maximum of 100 per request), mail:
>>>>>>    <dev-get.123_145@river.apache.org>
>>>>>> To get an index with subject and author for messages 123-456 , mail:
>>>>>>    <dev-index.123_456@river.apache.org>
>>>>>> They are always returned as sets of 100, max 2000 per request,
>>>>>> so you'll actually get 100-499.
>>>>>> To receive all messages with the same subject as message 12345,
>>>>>> send a short message to:
>>>>>>    <dev-thread.12345@river.apache.org>
>>>>>> The messages should contain one line or word of text to avoid being
>>>>>> treated as sp@m, but I will ignore their content.
>>>>>> Only the ADDRESS you send to is important.
>>>>>> You can start a subscription for an alternate address,
>>>>>> for example "john@host.domain", just add a hyphen and your
>>>>>> address (with '=' instead of '@') after the command word:
>>>>>> <dev-subscribe-john=host.domain@river.apache.org>
>>>>>> To stop subscription for this address, mail:
>>>>>> <dev-unsubscribe-john=host.domain@river.apache.org>
>>>>>> In both cases, I'll send a confirmation message to that address.
>>>>>> you receive it, simply reply to it to complete your subscription.
>>>>>> If despite following these instructions, you do not get the
>>>>>> desired results, please contact my owner at
>>>>>> dev-owner@river.apache.org. Please be patient, my owner is a
>>>>>> lot slower than I am ;-)
>>>>>> --- Enclosed is a copy of the request I received.
>>>>>> Return-Path: <bishnu35@hotmail.com>
>>>>>> Received: (qmail 76169 invoked by uid 99); 2 Sep 2012 00:48:45 -0000
>>>>>> Received: from athena.apache.org (HELO athena.apache.org)
>>> (
>>>>>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
>>> 00:48:45 +0000
>>>>>> X-ASF-Spam-Status: No, hits=2.4 required=5.0
>>>>>> X-Spam-Check-By: apache.org
>>>>>> Received-SPF: pass (athena.apache.org: domain of bishnu35@hotmail.comdesignates as permitted sender)
>>>>>> Received: from [] (HELO snt0-omc2-s2.snt0.hotmail.com)
>>> (
>>>>>>     by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Sep 2012
>>> 00:48:36 +0000
>>>>>> Received: from SNT145-W136 ([]) by
>>> snt0-omc2-s2.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);
>>>>>>     Sat, 1 Sep 2012 17:48:15 -0700
>>>>>> Message-ID: <SNT145-W136CD0261B4D1C6B55983A4C2A40@phx.gbl>
>>>>>> Content-Type: multipart/alternative;
>>>>>>    boundary="_8d4cc292-55ff-42a6-92f3-b39be91ffb52_"
>>>>>> X-Originating-IP: []
>>>>>> From: Bishnu Gautam <bishnu35@hotmail.com>
>>>>>> To:
>>>>>>    <dev-sc.1346546661.bpbohbfainpplmmplpaj-bishnu35=
>>> hotmail.com@river.apache.org>
>>>>>> Subject: RE: confirm subscribe to dev@river.apache.org
>>>>>> Date: Sun, 2 Sep 2012 00:48:15 +0000
>>>>>> Importance: Normal
>>>>>> In-Reply-To: <1346546661.69982.ezmlm@river.apache.org>
>>>>>> References: <1346546661.69982.ezmlm@river.apache.org>
>>>>>> MIME-Version: 1.0
>>>>>> X-OriginalArrivalTime: 02 Sep 2012 00:48:15.0984 (UTC)
>>> FILETIME=[A3545700:01CD88A4]
>>>>>> X-Virus-Checked: Checked by ClamAV on apache.org

View raw message