[Freeipa-devel] freeIPA v2: Access control for things not stored in LDAP

[Simo Sorce]

On Sun, 2008-11-16 at 20:57 -0700, Jason Gerard DeRose wrote:
> Say we have some operation that should be subject to access control,
> but
> does not involve something stored in LDAP... how should we enforce the
> access control?

This is a very good question.

> Here's the situation I'm thinking of: v2 has an "env" command that
> returns a list of (key, value) pairs describing the configuration
> state
> (run-time configuration, not the configuration stored in LDAP). In a
> client context, the command returns the client environment.  But with
> the --server option, it is forwarded to the server and returns the
> configuration state on the server.
> 
> Although this configuration data does not contain anything sensitive,
> we
> might want to restrict who can retrieve the server configuration.

Yes we may want to restrict it indeed.

> I know our general paradigm is to make LDAP responsible for enforcing
> access control. So should IPA be in the business of enforcing access
> control in special cases like the "env" command, or should we just
> avoid
> capabilities like this altogether? Does v1 have any special cases like
> this?

I think we should probably implement ACIs for each function call, and
attach default ones at installation time. We should probably think if it
make sense to store them in LDAP in this case, although it may also be
useful to have different ACIs depending on which server you contact.
I am not sure we really want to store them centrally and have them all
identical, probably not, it would be too inflexible. Besides they will
probably rarely be changed, if we use groups the right way I am sure in
most cases people will just need to change group memberships.

We could mimic the LDAP server format so that they will be familiar and
easily comparable to LDAP ACIs, we want them to use the same ID used on
the LDAP side too. Right now we use DNs in ldap, but we might switchy to
UUIDs some day, we should be able to support both (means we probably
need a look aside cache for the XML-RPC ACI code that maps kerberos
principals to the entry UUID and DN).

I would also make the ACIs inheritable, so that they can apply to child
objects. To make it easier to apply ACIs it would be nice therefore to
group commands in logical units. Make this "group of commands" a parent
of the specific commands, and apply the ACI to it.

How difficult is it to change the core code to add ACIs and a generic
enforcement code that operates before anythng else is called on the
server side and returns "permission denied" if the user connecting does
not have rights on that command ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York