If the access control object used as part of a MAC rule were to allow anyone other than a security officer to update it, users could evade the intention of mandatory control.
To what has already been defined, we add a boolean function d(o) which indicates whether an object o is subject to mandatory (MAC) or discretionary access control (DAC); this is a function d(o) on the object itself, rather than part of an access control object. We represent d(o) by a value tabulated within each object's primary catalog and do the same for a(o), which identifies the access control object protecting o, for o(o), which identifies the owner of o, and for r(o), which identifies the permission function to be used to interpret the access control information.
In summary, DACM behavior depends on whether or not a permission function and/or an access control object is defined for the object o, as shown in Table II.
-- ACCESSRULE identifies an access control object, a special ADF rule, or a null.
-- ACCESSRULE identifies the access control object to be automatically attached to items this subject creates;
Items are grouped into sets with common access control lists by the ACCESSRULE field in the ITEMS table; values in this field are the item identifiers of access control objects. Each access control object is interpreted by a permission function which it selects (Section 2.6) by fields in its catalog entry (Section 3.3) and must conform to rules specified by the author of this permission function.
Each stored object can bind both an access control object and a permission function and can choose its permission function either directly or via its access control object.
We believe that most users will create fewer than 10 lists with fewer than 10 subjects or groups in each, i.e., a large access control object collection will comprise 100 x [N..sub.u] table entries for [N.sub.u] users, using less than 1MB for 1000 users.
DACM structure follows object-oriented practice in that access control information is bound to an object by having the object point to an access control object and by having the access control object point to its interpretation method.
-- one or more classes would define access control information management; an instance of such a class would be what we have called an access control object;
-- any object needing protection would bind an access control object as an attribute, by calling a polymorphic ObjectBindAccessInformation operator during its creation; such a binding would persist until explicitly changed;
-- an access check would be a message passing the current subject and an integer to the associated access control object; such messages would be issued by the protected object's sensitive methods, i.e., implemented conventionally as part of the class definition of the protected object;