river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: monitoring security checks in a distributed environment
Date Sat, 20 Aug 2011 05:20:51 GMT
Gregg Wonderly wrote:
> On 8/18/2011 10:16 PM, Peter Firmstone wrote:
>> Getting security policies right in a distributed environment is 
>> difficult,
>> getting information back when things break in deployment is also 
>> difficult.
>> What would be nice is a service you can utilise to give you a list of 
>> failed
>> security checks and the failed ProtectionDomain's.
>> ProtectionDomain isn't Serializable and neither is ClassLoader (although
>> PrefferedClassLoader overrides toString()).
>> But we could call ProtectionDomain.toString() and serialize that.
>> I thought about using RemoteEvent's, however an attacker could use 
>> this for DOS
>> attacks. Instead, each node could register a SecurityAudit service 
>> with the
>> lookup service. It would be up to an administrator client to contact it.
>> Then you could use that service to periodically retrieve a list of 
>> failed
>> permission checks.
>> Or, we could log it? But logging doesn't seem to work too well from the
>> extension classloader...
>> But if we did use logging we could create a remote logger service, 
>> where an
>> administrator could inspect logs remotely...
> My logman.dev.java.net project provides this with command line 
> activation.  Just set the LogManager class, and the configuration 
> file, and you get remotely accessible logging as well as configuration 
> of log levels.
> Gregg
I like the sound of that Gregg, you've spent plenty of time dealing with 
these issues.

What are the security risks of logging failed permission checks?

Does anyone want this feature?

The big picture:

You're having trouble with some services in your djinn, so you check 
your client logs remotely, find you're missing some permissions (a list 
of the permissions the proxy needs and those it has are listed), you 
update your remote policy because you find your users don't have 
GrantPermission for a the needed permission and the problem is fixed.



View raw message