[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 19:15:41 -0800

On Jan 14, 2006, at 6:24 PM, Raif S. Naffah wrote:

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

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

But if the calling code does not have `PropertyPermission("...", "write"),' it can't call `System.setProperty.' Where's the problem?

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

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";

What I meant was that `Foo.doFrob' is a part of the system code -- that is, a part of Classpath, and therefore has all permissions. So all that's required is that `doFrob' access those resources (which is has permission to do) as a privileged action. I'm saying that `doFrob' is protected by some other permission `FrobPermission,' and just the virtue of `doFrob' reading some other privileged resource does not necessarily mean that the caller of `doFrob' needs any permission beyond `FrobPermission.'

In the case of JAAS, to call e.g. `Configuration.refresh', you need the permission: ("refreshLoginConfiguration");

...and nothing else. Presumably this means you can call that method even if you don't have any `PropertyPermissions' granted to you. IOW, it doesn't make sense if GnuConfiguration.refresh throws a SecurityException if the caller has `AuthPermission ("refreshLoginConfiguration")' but doesn't have, say, `SecurityPermission ("").' That this implementation requires other permissions to do its job isn't relevant.

(I looked over the patch again, and see that you'll only throw a SecurityException in `processSecurityProperties.' The other methods just fail silently (except for debug output) which I think is the wrong thing to do.)


reply via email to

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