(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!
_______________________________________________
Classpath mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
