Security [Was] Re: RemotePolicy service

[Peter Firmstone <ji...@zeus.net.au>]

Dan, you're wise and I respect your view.

Security matters to me because I plan to deploy over insecure networks.

Luckily security is mostly complete, Bob Scheifler's team achieved what 
they set out to do, a very difficult task I might add.  But this takes 
skill on the application developers part to understand and utilise.

For an application developer, determining policy files and permissions 
is often one of the big hurdles.

I get where you're coming from, deployment needs to be simpler and 
installation / configuration needs to be automagic.

To make it possible to add in security later, requires the application 
developer to follow certain rules and method calls.  These are typically 
very similar among different services.

I'm wondering if it's possible to use annotations to hide these methods 
from the application developer on the client side, so they can learn to 
develop without worrying about security, perhaps using only reflective 
proxy's to start with, then activate security later and start using 
smart proxy's when ready?

Typically we're talking proxy verification, dynamic permission grant's, 
running as Subjects, using key stores and using method constraints.

Cheers,

Peter.


Dan Creswell wrote:
> I recall Waldo saying some time ago that systems get harder and harder
> to do as you in order from:
>
> (1) Single-thread single machine.
> (2) Multi-thread single machine.
> (3) Multi-machine.
> (4) Multi-machine with security.
>
> On that basis, I'm tempted to say we should make our lives easier by
> setting something that limits the amount of heavy-lifting we need
> before we have anything to show for it/play with. Thus, I'd say we do,
> in order:
>
> (1) We should look at easing the admin burden - in terms of scooping
> up exceptions, logging, monitoring and such.
> (2) Sort out a bare bones out of the box experience - minimal configs,
> intelligent auto-setup for network interface selection.
> (3) Security for all the above.
>
> Now, I know and it's right to say on some levels, baking in security
> from the start often is what needs to be done but Jini itself managed
> without security early on and we probably ought to plan to "throw one
> away" (as per Mythical Man Month) as we figure these things out so I
> personally believe security can wait.
>
> +1 for doing as much through JMX as possible by default if that's
> practical (fear with multiple JVMs on one box a la simulating
> distributed services it might get tough).
>   

Re: Security [Was] Re: RemotePolicy service

[Peter Firmstone <ji...@zeus.net.au>]

Dan Creswell wrote:
> Hi Peter,
>
> On 4 August 2011 03:43, Peter Firmstone <ji...@zeus.net.au> wrote:
>   
>> Dan, you're wise and I respect your view.
>>
>>     
>
> Thank you equally be careful how much wiseness you attribute to me and
> thus how much respect you give me - nobody is perfect! :)
>
>   
>> Security matters to me because I plan to deploy over insecure networks.
>>
>>     
>
> Yep, that's visible in your areas of focus in respect of River and
> given it's nasty stuff to play with I appreciate your focus.
>
>   
>> Luckily security is mostly complete, Bob Scheifler's team achieved what they
>> set out to do, a very difficult task I might add.  But this takes skill on
>> the application developers part to understand and utilise.
>>
>>     
>
> Agreed.
>
>   
>> For an application developer, determining policy files and permissions is
>> often one of the big hurdles.
>>
>>     
>
> Agreed.
>
>   
>> I get where you're coming from, deployment needs to be simpler and
>> installation / configuration needs to be automagic.
>>
>>     
>
> Quite - a routine problem is the selection of an interface that does multicast.
>   

Maybe we need a jira with a list of common difficulties experienced, so 
we can pick them off one by one.

>   
>> To make it possible to add in security later, requires the application
>> developer to follow certain rules and method calls.  These are typically
>> very similar among different services.
>>
>>     
>
> Absolutely.
>
>   
>> I'm wondering if it's possible to use annotations to hide these methods from
>> the application developer on the client side, so they can learn to develop
>> without worrying about security, perhaps using only reflective proxy's to
>> start with, then activate security later and start using smart proxy's when
>> ready?
>>
>>     
>
> Can I check I understand that annotations thing? I think you're saying
> that we'd use annotations on their code to identify methods we'd need
> to invoke for them or provide stub implementations for? Seems
> reasonable if that's the case.
>   

Correct.

> I would say reflective proxy's are the easy starting point, although
> if we're doing the annotations thing, maybe we can make it work
> reasonably for smart proxies too. In fact, maybe annotations are a way
> to make things nicer for all regardless of level of expertise. I think
> we'd have to allow things to work without annotations (lots of code
> out there already written) but....
>
>   

Now I must confess, I've quite happily used other peoples annotations, 
but admit to never having defined any.

We've got the ASM library, we could use this as an annotation processor, 
to weave in what people like to refer to as boilerplate code (well 
bytecode actually).

Existing code missing the annotations, wouldn't be affected.

I guess a good place to start is to identify the snippets of code we 
need to create, and what annotation types we should define.

>> Typically we're talking proxy verification, dynamic permission grant's,
>> running as Subjects, using key stores and using method constraints.
>>
>>     
>
> Uh huh - I think the toughest of those for newbies are dynamic
> permission grants and proxy verification (at least in the smart proxy
> case), possibly Subjects too.
>   

By using an annotation processor and including a permissions.perm file 
in META-INF, we could weave in code that fetches the permissions from 
the proxy jar and dynamically grants them, if the proxy is authenticated 
and verified and provided the caller has the necessary 
GrantPermissions.  In this case the caller is the client Subject.   
Since GrantPermission's are designed specifically for Dynamic grants, 
there is an assumption that the client will grant these to proxy's it 
can authenticate.

We could weave in the code that does proxy verification too.  Then the 
application developers only needs to work out how to run as a Subject.

The following questions remain:

   1. Does the client Subject need to know the permissions it is about
      to grant?
   2. Is it an acceptable compromise to assume the client Subject is
      prepared to grant these permissions to the proxy of any
      authenticating service?
   3. GrantPermission(AllPermission) would be a security risk.
   4. The client Subject can have a wider scope of permissions than
      those it has GrantPermission for, so it would be an administrator
      choice what Permissions users can grant.
   5. It's generally bad practise to ask the user directly if they want
      to grant permission, they often mindlessly just say:  "Yes! I want
      to see the flying pig video!"
   6. Do we need to retrieve the service's authenticating, Subject
      retrieve its Principal's and use that information to make a
      decision about the permissions the client's prepared to grant? 
      This sounds too fine grained to me.  We probably want something
      that works most of the time, is relatively secure.
   7. Signed jar files can be used to restrict class loading with
      DownloadPermission granted to signers, this improves security,
      Authenticating the service and using proxy verification is a way
      of saying, I can trust the code because I trust the authenticated
      Service and it trusts the code.  Signing the code is a way of
      improving trust in the code, but it doesn't authenticate the
      Service and the Service still needs to know if the proxy belongs
      to it.

Cheers,

Peter.

Reference:  
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/com.ibm.websphere.osgifep.multiplatform.doc/topics/ca_java2sec.html


  Java 2 security and OSGi Applications

You can use Java 2 security in OSGi applications in a similar way to 
Java 2 security in Java EE applications. This topic describes the 
differences when you use Java 2 security in an OSGi application.

The OSGi specifications allow you to have permissions.perm files in the 
OSGI-INF directory of each bundle, so that you can apply fine-grained 
control to the permissions for each bundle. The OSGi Applications 
implementation in WebSphere® Application Server supports this 
specification, and also allows you to have a permissions.perm file in 
the META-INF directory of the OSGi application, which gives you 
coarser-grained control of the permissions for the application as a whole.

A permissions.perm file is a plain text file that contains comments or 
single-line permissions in the following form:

# Permissions file
( org.osgi.framework.AdminPermission "*" "*" )
( org.osgi.framework.PackagePermission "*" "exportonly,import" )
( org.osgi.framework.ServicePermission "*" "get,register")
( org.osgi.framework.BundlePermission "*" "host,provide,fragment")


    Relation to Java EE applications and was.policy files

These application-level permissions.perm files perform a similar 
function to was.policy files in enterprise applications. When you 
migrate an application from Java EE to OSGi, any existing was.policy 
file is converted into a permissions.perm file to be used with the OSGi 
permissions framework.

In the conversion, any codebases specified within the was.policy file 
are ignored, and all permissions specified are added to the 
permissions.perm file. This means that all permissions are promoted to 
the application level. If you need finer granularity, you can modify the 
file after conversion. In this case, you would remove the required 
permissions from the resulting permissions.perm file, and move them into 
permission files within the OSGI-INF directory for each affected bundle.





>   
>> Cheers,
>>
>> Peter.
>>
>>     
>
> Two cents,
>
> Dan.
>
>   
>> Dan Creswell wrote:
>>     
>>> I recall Waldo saying some time ago that systems get harder and harder
>>> to do as you in order from:
>>>
>>> (1) Single-thread single machine.
>>> (2) Multi-thread single machine.
>>> (3) Multi-machine.
>>> (4) Multi-machine with security.
>>>
>>> On that basis, I'm tempted to say we should make our lives easier by
>>> setting something that limits the amount of heavy-lifting we need
>>> before we have anything to show for it/play with. Thus, I'd say we do,
>>> in order:
>>>
>>> (1) We should look at easing the admin burden - in terms of scooping
>>> up exceptions, logging, monitoring and such.
>>> (2) Sort out a bare bones out of the box experience - minimal configs,
>>> intelligent auto-setup for network interface selection.
>>> (3) Security for all the above.
>>>
>>> Now, I know and it's right to say on some levels, baking in security
>>> from the start often is what needs to be done but Jini itself managed
>>> without security early on and we probably ought to plan to "throw one
>>> away" (as per Mythical Man Month) as we figure these things out so I
>>> personally believe security can wait.
>>>
>>> +1 for doing as much through JMX as possible by default if that's
>>> practical (fear with multiple JVMs on one box a la simulating
>>> distributed services it might get tough).
>>>
>>>       
>>     
>
>   

Re: Security [Was] Re: RemotePolicy service

[Dan Creswell <da...@gmail.com>]

Hi Peter,

On 4 August 2011 03:43, Peter Firmstone <ji...@zeus.net.au> wrote:
> Dan, you're wise and I respect your view.
>

Thank you equally be careful how much wiseness you attribute to me and
thus how much respect you give me - nobody is perfect! :)

> Security matters to me because I plan to deploy over insecure networks.
>

Yep, that's visible in your areas of focus in respect of River and
given it's nasty stuff to play with I appreciate your focus.

> Luckily security is mostly complete, Bob Scheifler's team achieved what they
> set out to do, a very difficult task I might add.  But this takes skill on
> the application developers part to understand and utilise.
>

Agreed.

> For an application developer, determining policy files and permissions is
> often one of the big hurdles.
>

Agreed.

> I get where you're coming from, deployment needs to be simpler and
> installation / configuration needs to be automagic.
>

Quite - a routine problem is the selection of an interface that does multicast.

> To make it possible to add in security later, requires the application
> developer to follow certain rules and method calls.  These are typically
> very similar among different services.
>

Absolutely.

> I'm wondering if it's possible to use annotations to hide these methods from
> the application developer on the client side, so they can learn to develop
> without worrying about security, perhaps using only reflective proxy's to
> start with, then activate security later and start using smart proxy's when
> ready?
>

Can I check I understand that annotations thing? I think you're saying
that we'd use annotations on their code to identify methods we'd need
to invoke for them or provide stub implementations for? Seems
reasonable if that's the case.

I would say reflective proxy's are the easy starting point, although
if we're doing the annotations thing, maybe we can make it work
reasonably for smart proxies too. In fact, maybe annotations are a way
to make things nicer for all regardless of level of expertise. I think
we'd have to allow things to work without annotations (lots of code
out there already written) but....

> Typically we're talking proxy verification, dynamic permission grant's,
> running as Subjects, using key stores and using method constraints.
>

Uh huh - I think the toughest of those for newbies are dynamic
permission grants and proxy verification (at least in the smart proxy
case), possibly Subjects too.

> Cheers,
>
> Peter.
>

Two cents,

Dan.

>
> Dan Creswell wrote:
>>
>> I recall Waldo saying some time ago that systems get harder and harder
>> to do as you in order from:
>>
>> (1) Single-thread single machine.
>> (2) Multi-thread single machine.
>> (3) Multi-machine.
>> (4) Multi-machine with security.
>>
>> On that basis, I'm tempted to say we should make our lives easier by
>> setting something that limits the amount of heavy-lifting we need
>> before we have anything to show for it/play with. Thus, I'd say we do,
>> in order:
>>
>> (1) We should look at easing the admin burden - in terms of scooping
>> up exceptions, logging, monitoring and such.
>> (2) Sort out a bare bones out of the box experience - minimal configs,
>> intelligent auto-setup for network interface selection.
>> (3) Security for all the above.
>>
>> Now, I know and it's right to say on some levels, baking in security
>> from the start often is what needs to be done but Jini itself managed
>> without security early on and we probably ought to plan to "throw one
>> away" (as per Mythical Man Month) as we figure these things out so I
>> personally believe security can wait.
>>
>> +1 for doing as much through JMX as possible by default if that's
>> practical (fear with multiple JVMs on one box a la simulating
>> distributed services it might get tough).
>>
>
>