Re: security features for kawa

[thomas kirk <tk at research dot att dot com>]

 > +1 from me.
 > 
 > I think JVM security is terribly underutilized.  Partly due to it's 
 > inconvenience.  Being able to easily configure it from Kawa would be a 
 > great feature.
 > 


Indeed, the use of the java security architecture in dynamic languages that
target the JVM seems unfortunately rare (I believe Groovy does something similar
to what I've implemented for Kawa). I've found the combination of Kawa and JVM
an indispensable platform for building distributed applications that are 
fully adaptive at runtime without sacrificing security.

That said, my stuff doesn't really address configuring security policies,
just using them, i.e. we use the existing policy implementation (the policy
file can contain an arbitrary number of security contours which can be
dynamically selected by the compiler). There's undoubtedly opportunity for 
improvement here.

I'm not familiar with XDoclet. Are you suggesting that this is perhaps a 
mechanism for building and maintaining security policies?
(as noted above, this could be done independently of the way Kawa
uses the policy).

tom


 > While my project is still in the contemplation stage, fine-grained 
 > sandbox control is something I would definitely use if it was convenient 
 > (i.e., configurable in the source).
 > 
 > OOAT:  I wonder whether there is a Java security policy XDoclet?  That's 
 > something that is essential before developers start to make widespread 
 > use of the security policies (as opposed to every production system I've 
 > worked on to date which puts in a single all-permissions for the whole 
 > codebase when they get their first security exception and leaves it at 
 > that).
 > 
 > Jim
 > 
 > Thomas Kirk wrote:
 > 
 > > I've modified Kawa's classloaders to support annotation of compiled code
 > > to work with the java security manager, so that scheme code may be
 > > subject to runtime permission checking. Given the way code is loaded in
 > > Kawa, this allows very fine-grained sandboxing -- permissions can be
 > > assigned at the granularity of individual functions. In my application,
 > > this has been a useful mechanism for containment of code that is
 > > distributed at runtime, and for controlling resource access by 
 > > untrusted code.
 > > 
 > > I can contribute this functionality back into the Kawa codebase if others
 > > are interested. It would need some additional work to be made ready for 
 > > general use, so I'd like to gauge interest before submitting patches.
 > > 
 > > cheers...
 > > tom
 > >