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 -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...
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
former.
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.
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";
...
};