This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: gcj-security and some issues
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