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
pgpESBdvrmANC.pgp
Description: PGP signature
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
