Re: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for

[Casey Marshall]

(Moving to the list to avoid attaching all of this to the bug).

On Jan 14, 2006, at 4:56 PM, raif at swiftdsl dot com dot au wrote:

> On Sunday 15 January 2006 11:21, csm at gnu dot org wrote:
> > ------- Comment #10 from csm at gnu dot org  2006-01-15 00:21 -------
> > Subject: Re:  javax.security.auth.login.LoginException: no configured
> > modules for
> >
> > On Jan 14, 2006, at 3:02 PM, raif at swiftdsl dot com dot au wrote:
> > > On Sunday 15 January 2006 09:29, csm at gnu dot org wrote:
> > > > That is, code should be permitted to use JAAS, but NOT permitted
> > > > to read anything sensitive at the same time.
> > >
> > > the use of the Configuration (and its subclasses) is itself
> > > conditioned
> > > by security properties; e.g. the refresh() method.  why then would
> > > you want to respect that restriction on the Configuration itself
> > > but bypass
> > > it in its implementation?
> >
> > Those are (I believe) separate permissions; as a user of JAAS, I'd
> > expect if I'm granted permission to use JAAS, then I should be able
> > to use it, whether or not that means the *implementation* of JAAS
> > does something else that requires permission.
> >
> > I mean, why should a programmer using the JAAS API have to care about
> > what goes on behind the scenes?
>
> let's consider this scenario:
>
> 1. GnuConfiguration bypasses security checks and reads system  
> property.
> 2. rogue user A usually has no login access to application ACME, and
> does not have permission to read/write the jass config system related
> properties.
> 3. A writes a phony login module and specifies it in a config file at
> location L.
> 4. A then calls java -Djava.security.auth.login.config=L ...
>
> A now can login into previously unauthorized ACME!

I think that argument is a little specious. The `java -D...' feature  
is a part of a command-line interface to a Java runtime; it is NOT a  
feature of the Java platform. An applet can't exploit this, nor can  
anything inside an already-running VM, and that is what the Java  
security model is concerned with.

Most VMs treat the `-Dfoo=...' option as implying a temporary  
PropertyPermission to write the property `foo.' There is no reason  
why a VM has to do this, however -- a VM could require that the main  
class MUST have that PropertyPermission, in order to accept the `-D'  
option; or it might not support that option at all.

I also don't exactly see why the scenario you suggest is exploitable  
if PropertyPermissions are bypassed internally, but not exploitable  
otherwise. Someone can call `java - 
Djava.security.auth.login.config=L' regardless, right? If some  
application depending on JAAS is vulnerable to that, it's generally  
vulnerable.

> in the current implementation of GnuConfiguration, A has to change the
> security policy to be granted read access to jaas related properties
> before succeeding.
>
>
> > > > SystemProperties is just more convenient than using
> > > > AccessController to accomplish this; we will probably add a
> > > > SecurityProperties class that does the same thing.
> > >
> > > this only addresses system properties, what about the security
> > > properties and file reading?  are you implying running (all) the
> > > Configuration logic as privileged code?
> >
> > Obviously not, but running the parts that require permission -- which
> > the caller may not have or need -- should be...
>
> like the scenario above shows.  doing it the way you propose may  
> lead to
> undesirable effects.

I still don't get it. Say we have the method `Foo.doFrob(),' which  
requires that the caller have `FrobPermission.' It doesn't require  
any other permissions. If our *implementation* of `doFrob' needs to  
read a system property, it needs `PropertyPermission' for that, but  
the caller of `doFrob' doesn't, so the implementation of `doFrob'  
must run that part of the code as privileged.

> (i didn't think this would generate so much traffic!  i hope i'm not
> sounding stubborn)

Not at all! In fact, I was afraid I might sound stubborn. I like this  
kind of discussion, because in the end it should help ensure that  
Classpath's implementation is the best it can be!