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

[Raif S. Naffah]

On Sunday 15 January 2006 12:23, Casey Marshall wrote:
> 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:
> >> 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...

i used java -D in the scenario above but feel free to replace it with 
System.setProperty(...).  now the latter is not restricted as the 
former.


> 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.

because in a coherent situation if i don't want to allow A setting their 
own login config files and classes, and hence indirectly bypassing / 
replacing my authorization (login modules), i would not grant A 
read/write permissions to the jaas-related properties.


> >>> 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.

... or in the security policy file, grant the caller read/write 
permissions to the doFrob property permission; e.g.

grant codeBase "file:myDoFrobImpl.jar" {
  permission java.util.PropertyPermission "doFrob", "read";
  ...
};

grant codeBase "file:yourDoFrobImpl.jar" {
//  no doFrob for you
//  permission java.util.PropertyPermission "doFrob", "read";
...
};


cheers;
rsn

pgpdAk4bMTW54.pgp
Description: PGP signature