gcj-security and some issues

Tue Apr 27 07:26:00 GMT 2004

Am Dienstag, 27. April 2004 09:11 schrieb Jakob Praher:
> 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/AccessControllContex
>t;
>>> 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.

Your analysis seems quite correct BUT the biggest problem yet is that 
StackTrace's implementation is just crap. The solution you provided is 
nearly the same I did here some days ago until I found out that 
StrackTrace is so dumb (it calls external apps to analyze the 
stack ...). Bryce McKinley is working on a better solution. The base 
has to be built first before we can build the roof.
Michael