Re: Access to LdapPrincipal constructor

[Niclas Hedhman <ni...@hedhman.org>]

On Saturday 30 April 2005 11:02, Alex Karasulu wrote:
> Ahh yeah I thought I confronted this at some point.  I have to refresh
> myself.  Basically LdapPrincipal can only be created by the Auth service
> you are right.  This is for security reasons and the reason while we
> keep it package friendly.  I know I made some kind of changes to
> accommodate a way for your Authenticators to be ok with this.

Alex, I don't know if you have thought about how the ApacheDS is secured over 
all. Protecting fields, methods and constructors is no real protection at 
all, unless combined with proper security policies and the use of 
AccessController.doPriviliged().

If no such thoughts has been spent on the subject, perhaps it is soon time to 
start a security review of the entire system.


Cheers
Niclas

Re: Access to LdapPrincipal constructor

[Alex Karasulu <ao...@bellsouth.net>]

Niclas Hedhman wrote:

>On Saturday 30 April 2005 11:02, Alex Karasulu wrote:
>  
>
>>Ahh yeah I thought I confronted this at some point.  I have to refresh
>>myself.  Basically LdapPrincipal can only be created by the Auth service
>>you are right.  This is for security reasons and the reason while we
>>keep it package friendly.  I know I made some kind of changes to
>>accommodate a way for your Authenticators to be ok with this.
>>    
>>
>
>Alex, I don't know if you have thought about how the ApacheDS is secured over 
>all. Protecting fields, methods and constructors is no real protection at 
>all, unless combined with proper security policies and the use of 
>AccessController.doPriviliged().
>
>If no such thoughts has been spent on the subject, perhaps it is soon time to 
>start a security review of the entire system.
>  
>
Yah that's long overdue.  Of course I've thought about using privledged 
actions.  Field protection is just minimal since we did not do all the 
needed work for securiting it.  Basically we should have a Permission 
for being able to create such a principal to protect creation of an 
LdapPrincipal. 

We need more hands here to do this additional work.  Otherwise I'm going 
to have to get to it when I can. 

FYI privledged actions will be key when we have code used for stored 
procedures in the server.  Can't take the next big leap without it.

Alex

RE: Access to LdapPrincipal constructor

["Noel J. Bergman" <no...@devtech.com>]

Niclas Hedhman wrote:
> Noel J. Bergman wrote:
> > > If no such thoughts has been spent on the subject, perhaps it
> > > is soon time to start a security review of the entire system.
> > Do you want to make that review a project for yourself?
> Thinking about it, but I definately need some tough peer reviews
> to make it water tight.

I don't expect that to be a problem.  :-)

	--- Noel

Re: Access to LdapPrincipal constructor

[Niclas Hedhman <ni...@hedhman.org>]

On Monday 02 May 2005 23:16, Noel J. Bergman wrote:
> > If no such thoughts has been spent on the subject, perhaps it is soon
> > time to start a security review of the entire system.
>
> Do you want to make that review a project for yourself?

Thinking about it, but I definately need some tough peer reviews to make it 
water tight.

Cheers
Niclas

RE: Access to LdapPrincipal constructor

["Noel J. Bergman" <no...@devtech.com>]

Niclas Hedhman wrote:

> Protecting fields, methods and constructors is no real protection at
> all, unless combined with proper security policies and the use of
> AccessController.doPriviliged().

This is not necessarily an issue for the core code, although it could be if
we want to provide maximum control to administrators, but should be applied
to all pluggable code.

> If no such thoughts has been spent on the subject, perhaps it is soon
> time to start a security review of the entire system.

Do you want to make that review a project for yourself?

	--- Noel