[Next] [Up] [Previous] [Contents]
Next: 4.4 Implementor Up: 4.3 Administrator Previous: 4.3.8 [IMAGE ]What about

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

 
change_begin

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:

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

Polar Humenn:
(June 1999)27:
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)28:
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.

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.


change_end


[Next] [Up] [Previous] [Contents]
Next: 4.4 Implementor Up: 4.3 Administrator Previous: 4.3.8 [IMAGE ]What about