[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: security suggestion for openldap

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Matthieu Turpault

> To satisfy
> their requirements of security, it would be necessary to add
> the following
> features:
> 	- restrict the rights of the manager of the directory.
> Indeed, the person
> in charge of the ACL management should not be able to read
> the data of the
> directory. It is essential that these two features are
> clearly separated.

I've worked on such segregated-rights operating systems before. I believe the
concept is inherently flawed. An admin user with the privilege to manipulate
ACLs can grant whatever rights desired to any user, thereby sidestepping this
artificial limitation by working with a separate account. Segregating read
privilege from ACL manipulation privilege does not in any way enhance
security; it only increases obfuscation and makes effective management that
much harder.

> 	- the content of the database should be encrypted in
> full. It should not be
> possible to read the data with vi or an other text editor.

The databases are binary files; vi will surely not read it. Emacs probably
can, but I don't consider that an ordinary text editor... This requirement is
poorly specified.

> 	- non-authenticated user should not extract
> information. ?root? user should
> not be able to extract the data in the directory.

Without altering the kernel, you cannot prevent root from doing whatever it
wants. If the database is encrypted then you may be safe, but you cannot
store the encryption key anywhere on the system or anywhere accessible from
the system, otherwise root will be able to retrieve it. This pretty much
means that whenever the system is restarted, some human admin must be present
to type in the encryption key.

> I am aware of the importance of the developpement that I am
> asking for but I
> think that it will be mandatory to turn openldap into a more
> considered product.

I disagree.

> It?s unlikely to notice that such an efficient and stable
> product presents
> such flaws in the security fields.

You have not identified any real software flaws. You've merely pointed out
that your security administrators cannot be trusted to do their work without
reading data they shouldn't have. No amount of software architecture will
prevent such untrustworthy admins from reading whatever they wish. You have a
social problem; social problems can only be solved by social means, not thru

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support