[Top][All Lists]

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

Re: [Bug classpath/25202] no c

From: Raif S. Naffah
Subject: Re: [Bug classpath/25202] no configured modules for
Date: Sun, 15 Jan 2006 13:24:09 +1100
User-agent: KMail/1.9.1

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

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

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


Attachment: pgpdAk4bMTW54.pgp
Description: PGP signature

reply via email to

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