[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug classpath/25202] no c

From: Casey Marshall
Subject: Re: [Bug classpath/25202] 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: 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
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
3. A writes a phony login module and specifies it in a config file at
location L.
4. A then calls java ...

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 -' 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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]