|
From: | Casey Marshall |
Subject: | Re: [Bug classpath/25202] javax.security.auth.login.LoginException: no configured modules for |
Date: | Sat, 14 Jan 2006 17:23:01 -0800 |
(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 toundesirable 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!
[Prev in Thread] | Current Thread | [Next in Thread] |