gcj-security and some issues

Tue Apr 27 07:11:00 GMT 2004

Am Die, den 27.04.2004 schrieb Michael Koch um 06:39:
> Yeah, you just described our general plan. Unfortunately this security 
> is not so easy to implement. Otherwise it would be done already. I 
> looked into all this lately and stopped soon because somethings are 
> missing that is being worked on by others. We need better stack tracing 
> support to implement AccessController for real. Currently this is more 
> or less a stub implementation. When AccessController is complete we can 
> start with the CodeSource stuff. Otherwise it makes no sense (at least 
> to me).
>>Great to hear that.
If you look at the javadoc of AccessController and
AccessControllContext, you'll notice that both have a checkPermission
Method.
So I think the real work that AccessController needs to do, is the
Method
AccessController.getContext()Ljava/lang/security/AccessControllContext;
This, afaik, can be already implemented using the
gnu.gcj.runtime.Stacktrace.
A sketch would look like: (this is just a little morning hack)
(based on the JavaSec book, page 105ff and some wild guesses by me)
 public static AccessControllContext getContext( ) {
 gnu.gcj.runtime.Stacktrace trace = new gnu.gcj.runtime.Stacktrace(
);
 List al = new ArrayList( trace.length( ) );
 // i think the call to getContext should be cut off the set
 Class pred = null; 
 ProtectionDomain pdpred = null;
 for ( int i = 1; i < trace.length; i++ ) {
 Class c = trace.classAt( i ) ;

 if ( pred != null && pred.equals( c ) ) continue;

 ProtectionDomain pd = null;
 if ( c != null ) pd = c.getProtectionDomain( );

 if ( pdpred != null && pdpred.equals( pd ) ) ) continue;

 if ( pd != null );
 al.add( pd );
 pdpred = pd;
 pred = c;

 }
 ProtectionDomain[] pds = (ProtectionDomain[])al.toArray( new
ProtectionDomain[ 0 ] );
 return new AccessControllerContext( pds ); 
 }
Acutally this implemention is quite naive, I assume if 2 trace entries
have the same class, only one is needed and if 2 concecutive classes on
the stack have the same ProtectionDomain, only one ProtectionDomain
should be kept.
I also *think* that the call to getContext should be cut of.
The doPrivileged methods, according to my book (j2se) are simple stop
markers in the stack trace, meaning that if a stack trace includes a
doPrivileged method, the AccessController/AccessControllContext will
stop. I could imagine that this could be implemented, by
* the accesscontroller just stops when a class equals
AccessController.class and the method is doPrivileged
* or by having a special ProtectionDomain attached to AccessController.
I think the first way would be better:
a naive implementation (could be)
 public static AccessControllContext getContext( ) {
 gnu.gcj.runtime.Stacktrace trace = new gnu.gcj.runtime.Stacktrace(
);
 List al = new ArrayList( trace.length( ) );
 // i think the call to getContext should be cut off the set
 Class pred = null; 
 ProtectionDomain pdpred = null;
 for ( int i = 1; i < trace.length; i++ ) {
 Class c = trace.classAt( i ) ;
 String m = trace.methodAt( i );
 if ( AccessController.class.equals( c ) && m.equals(
"doPrivileged" ) ) {
 break; 
 } 
 if ( pred != null && pred.equals( c ) ) continue;

 ProtectionDomain pd = null;
 if ( c != null ) pd = c.getProtectionDomain( );

 if ( pdpred != null && pdpred.equals( pd ) ) ) continue;

 if ( pd != null );
 al.add( pd );
 pdpred = pd;
 pred = c;

 }
 ProtectionDomain[] pds = (ProtectionDomain[])al.toArray( new
ProtectionDomain[ 0 ] );
 return new AccessControllerContext( pds ); 
 }
So this is all that the AccessController would need. The
AccessControlContext simply goes through all the ProtectionDomains it
has, and enforces that every ProtectionDomain has the permission.
I *think* this would be all that is needed to implement the
AcessController. I think this could be done anytime, and as soon as gcj
applies Codesoures to its classes one can start testing the
implemention. 
Sure the above is just a little hack by me, but at least it shows my
understanding of the issue.
-- Jakob
> Michael