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

[raif at swiftdsl dot com dot au]

------- Comment #11 from raif at swiftdsl dot com dot au  2006-01-15 00:56 
-------
Subject: Re:  javax.security.auth.login.LoginException: no configured modules
for

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!


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 didn't think this would generate so much traffic!  i hope i'm not 
sounding stubborn)


cheers;
rsn


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25202