4.3.9 How would access control mechanisms be applied to secure, let's say, naming service?

 

Extended Question:

(Paul H Kyzivat) : Consider a server implementing CosNaming. Now this server is available widely. Everyone can get a reference to an initial NamingContext. The NamingContext interface permits reading, writing, traversing, contexts as well as creation and destruction of new contexts. Now I probably don't want everyone to have free reign to do all of these things. Rather, I most likely want to administer it in similar way to how a file system is administered:

• Some set of users should have full access to the initial context.
• Most other users should be able to have access to read and traverse this initial context.
• Additional contexts will exist and be bound into the initial context. Full access to these should be grantable to other users.
• Repeat the above recursively.
• Other filesystem-like access control that I failed to mention.

Can you show me how CORBA Security can provide this functionality?

Polar Humenn:

(June 1999)²⁷:
If you prescribe to the Domain Access Policy and Required Rights model, this is how it should be done.

The first thing you have to do is define a RequiredRights object that each context will have access to. Logically, all contexts will see the same required rights object, but that cannot be enforced, since the naming context can bind contexts of different services coming from anywhere.

But lets say for the moment, the naming service and each context in it prescribes to the same required rights object however that is done.

Give the "resolve" operation on the naming context interface the "0 0 get" right, (0=family definer, 0=family) give the "bind" and "bind_context" operations the "0 0 set" right, with a combinator of SecAllRights.

Now, set up a domain manager for each context! Each domain manager must have a SEPARATE Access Policy.

For each Access Policy you narrow it to a DomainAccessPolicy and you must give the "0 0 get" right to the one attribute that represents the user. (This could be SecAttributeType (0,1,2) Access Id (0=family definer, 1=family, 2=type). Give the "0 0 set" right to the attribute that represents users you want to be able to do binds.

Here are the limitations: The initial context will have a problem, however, that you cannot specify the "get" right for "ALL" users. One would think that you could specify that "no" rights are required for access to the initial context's "resolve" operation and that would do it. However, if everyone prescribes to the same RequiredRights object, your hosed, because you wouldn't be able to protect the "resolve" operation on other contexts.

We did an experiment a while ago, trying to map Unix id's into CORBA and use the naming service as a map of a Unix file system. Each context was a directory, and each file was a CosSerializable object (or some such animal).

For each context, the context had to create "on the fly" a domain manager and an AccessPolicy object (not a DomainAccessPolicy object). This was easy, since the Naming Service in question was a single server and could do these sorts of things.

The AccessPolicy object mapped a certain security attribute representing the user to its corresponding Unix id, and threw back the rights, "read", "write", "search", according to the permissions of the Unix id based on its authorization information on the local system, i.e. owner, group, other.

However, we couldn't do that kind of policy with a plain DomainAccessPolicy, because there isn't a way, unless we had some sort of "wild-card" security attribute, that you could say "other". But even then the specification of the DomainAccessPolicy rules aren't good enough to do an ordered check, say, first check "owner", then check "group", then check "other" relationships.

Bob Blakley

(June 1999)²⁸:
There are actually a couple of ways (in detail) to do it. I'll give one example.

Naming context is an interface, so it needs to have an entry in a RequiredRights table. Add this interface to the system's unique RequiredRights object and set up required rights for the its methods. For purposes of argument, map "read" and "traverse" operations to the "g" right and other operations to "s". This may be too simplified; if a more complex mapping is required it's straightforward to produce it. If you need one, a custom rights family can be defined.

• Some set of users should have full access to the initial context

  Right. Form a group "InitialContextAccessors". Add the privilege attribute corresponding to this group to the credential of each user who is to be granted full access to the initial context.

• Most other users should be able to have access to read and traverse this initial context

  Right; form another group "InitialContextLimitedAccessors". Add the privilege attribute corresponding to this group to the credential of each of the users who does not have full access, but does have "read and traverse" access to the initial context.

  Now put the context object into a domain. Give it an ACL with two entries; one which grants "gs" to "InitialContextAccessors" and another which grants "g" to InitialContextLimitedAccessors".

• Additional contexts will exist and be bound into the initial context. Full access to these should be grantable to other users.

  Not clear exactly what you mean here, but I'm guessing what you mean here is that the same users who have access to the parent context also have the same level of access to all embedded contexts; additionally some other set of users who do not have access to the initial context should have at least some rights (full access in your example) to the embedded context.

  There are a couple of ways to do this; depending on your implementation you may have several options. If your implementation allows nested domains (i.e. domains within domains) then you've got an easy task here:

  Simply create a new domain and put it in the first domain. Add the embedded context to the new domain. This will have the effect of causing the embedded context to inherit the policy governing the initial context. Now:

  1.

  Create a new group "FirstEmbeddedContextAccessors".

  2.

  Add the privilege attribute corresponding to this group to the credential of all users who should have access to the users who have access to the embedded context (including perhaps some who don't have any access to the initial context).

  3.

  Create an ACL (i.e policy object) for the new domain. Give it one entry, which grants "gs" to "FirstEmbeddedContextAccessors".

• repeat the above recursively.

  repeat the above recursively.

This results in a structure with one domain per context, one ACL per domain, and (on average, excluding one extra entry in the initial domain) one entry per ACL. Each user is a member of as many groups as the domains he needs to access. The policy data here scales as follows:

1.

Domains: linearly proportional (n=1) to the number of naming contexts to be protected

2.

ACL data: ACLs AND entries linearly proportional (n=1) to the number of contexts to be protected, but policy is inherited reducing what would otherwise be an n*log(n) scale.

3.

Groups: for each user, linearly proportional to the number of naming contexts which the user needs to access - but this is worst case, assuming that user populations needing to access disjoint naming contexts are always disjoint. If naming contexts overlap substantially in authorized user populations, then you can achieve sub-linear scale here.