4.3.1 What are the semantic connotations for rights in CORBA rights family?

 

Extended Question

Gerald Brose: ``The Security Service Specification (Rev 1.2) specifies an default access control policy. This policy uses "rights" for authorizations. Also, a default rights family "corba" for use with the domain access policy is defined (p.15-124) that has rights (s,g,m,u) for set, get, manage and use. The option of defining new rights families, is severely limited by the definition of rights families as structs, and is explicitly discouraged in the spec. to keep things simple.

Actually, I think this is absolutely inappropriate, but I might be missing the essential points that justify this design. My question therefore is:

Given that the corba rights family is intended to serve most cases, what exactly are the semantic connotations for these four rights? Are they simply chosen in an ad hoc way, or is there some deeper reasoning behind this choice, such as why it would make administration easier in some cases? If so, how and in which cases?''

Bob Blakley (April, 1998):

This is a good question, and one which we discussed extensively during the initial definition of the specification. The basic motivation for defining a small, standard set of rights and strongly encouraging everyone to live with that set is that there are a potentially unlimited number of methods in any given CORBA system (each new class can introduce large numbers of them), and the set of methods is semantically very complicated from the viewpoint of the administrator - methods with the same name may do different things, methods with different names may do the same thing, methods may have names which do not at all suggest their function or sensitivity, and methods belonging to the same class may have very different consequences if invoked on different instances with different internal states. This makes it almost impossible for administrators to manage policy using methods. Rights are thus introduced as a way to "group" methods. We could have stopped after introducing the notion of rights, and allowed implementors or even administrators to define arbitrary collections of rights, but we felt that this would lead to a chaotic situation in which the population of rights would be widely variable across different vendors' implementations and different customers' or even departments' deployments, making training and interoperability a nightmare.

We chose instead to conceive of rights as a kind of language, to be used definers of new object classes to communicate the sensitivity of their classes' methods to the security administrator. We defined a small language of rights which corresponded generally to the KINDS of operations which an object-oriented system's methods perform, namely:

method reads and returns one of the object's data members method writes one of the object's data members method executes one of the object's member functions

We defined a right corresponding to each of these basic KINDS of operations, and added one more right to deal with the real-world fact that some operations of the same KIND are more sensitive than others of the same KIND.

Hence the intended semantic connotations of the rights in the "corba" family are:

s ("set"):

required to access methods which modify an object's internal state (e.g. setter methods for data members)

g ("get"):

required to access methods which return, but do not change, an object's internal state (e.g. accessing readonly attributes or other data members; getter methods)

u ("use"):

required to access methods which perform computations or call other objects (e.g. member functions)

m ("manage"):

required, usually in addition to one of the other three rights, to access methods which perform management activities, are unusually sensitive, or are otherwise intended for use only by specially privileged callers.

Note that these semantics are NOT "exact" in the sense that they have neither formal nor normative definitions. Nevertheless, I think it's quite clear to both class definers and system administrators what they are supposed to mean, and how they can be used.

Clearly they aren't an exact match for all possible security policies in a CORBA environment, but I don't think a system which supports an exact match for all possible policies would be one which could be administered by normal humans.