This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

question about security impl


hi all,

over the past years I worked quite a bit with java security api and
found/find the book "Java Security" by Scott Oaks very valueable.

when calling:

AccessControlContext acc = AccessController.getContext( );

one should get the current callstack (naive spoken, I mean the
coudesources and the permissions of that classes who have methods on the
call stack in order on which they appear on the stack ) as a
ProectionDomain array. (Since a ProtectionDomain is a grouping of a code
source and permissions). 

Actualy the current source implements this as:

new AccessControlContext( new ProtectionDomain[ 0 ] );

I would like to discuss how this could be implemented (or maybe I am
missing something). 

* CodeSoure path differences between jar/directory locations and shared
object files
* Callstack information must be provided in a way that the
AccessController at the current Callframe can get the information about
all ProtectionDomains of ancestor frames. (this should be no problem I
think, since we can get all the Methods of the call stack and thus we
could get all the Classes of the call stack, and via the classes we have
access to the protectiondomain)
* ProtectionDomain Information, that means, CodeSource and Permissions
when the class gets loaded.
* Is there a way to do this safely in gcj? Maybe one could simply not
allow foreign unsigned code to contain native compiled code per default.
So that translation to native code takes place at a "safe" place.
* The PrivilegedAction thing - which is all about saying "look as far as
this but not further down the call stack", when creating an
AccessControlContext.
* sealing shared objects? this should be hard to do since its a trust
problem (but I think we can't verify/check native code in a timely
manner)
 
The majority of the security mechanics should be heavily optimized and
should/must be done within the gcj code.

I look forward to discussing these things with you.
(I am an gcj-apprentice and glad when learning something new about the
impl). 

-- Jakob 




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]