"A Layered Design of Discretionary Access Controls with Decidable Safety" S&P 2004 Solworth and Sloan SUMMARY In this paper, the authors present a general access control model which attains a unique balance of expressiveness and decidability. This model has three layers: the general access control model, the parameterization, and the local initialization. The parameterization is used to tailor the general access control model to a specific model which will be used in some application domain (for example, DAC with change of ownership), while the local initialization is used to set up the base users and groups in the system before it "goes live." In the general access control model, objects are tagged with labels and the groups of users with various permissions are defined on a per-label basis. This allows the permissions of multiple objects to be managed by changing the set of users with permissions on a single label. The system presented in this paper is flexible enough to represent a wide range of DAC models yet still has decidable safety properties. The authors show that several interesting safety properties are decidable in the access control model's first level of abstraction. This implies that these properties are also decidable at higher levels of abstraction, as these levels only restrict the expressiveness of the general access control model. The authors then show how to encode several DAC schemes using the 2nd level of their model, meaning that the safety properties are decidable for these DAC schemes. DISCUSSION POINTS 1. What are everyone's thoughts on the layered access control system design? Many products these days ship with *THE* access control system installed when you get it; in what situations could the ability to constrain or specify things further be helpful? 2. Is this paper primarily of theoretical or implementational significance? The HRU result says that the safety property is not decidable in the access matrix model, though it doesn't make the claim that it is undecidable for all DAC models. If this paper is mainly of theoretical interest, then I feel that the main result would be that they've shown that safety is decidable for the DAC systems, but I don't think that this is the main result. If it's an implementation paper, then wouldn't the primary contribution need to involve the range of access control models supported by this system and the ease with which the operations needed in these models can be supported? In essence, shouldn't the ease-of-use of this model be explored? 3. Is the relable system expressive enough? Consider the rule rl_n(<*u,*>,<*u,*>) = g from section 3.1. This says members of group g can relabel any two ordinary objects with the same 1st component. Can we think of situations where we want more constraints on the relabel? Can we express these constraints in the access control model presented in this paper? 4. Can anyone explain the first two rules of figure 2 in section 3.2? Is u_{relabel} not a wildcard? 5. It doesn't seem that relabel rules can be added once the system is running. Am I correct? If so, how would this impact the evolution of a "live" system? 6. Deletion is not included as one of the layer three operations in this system. For any model of more than theoretical interest, isn't this a necessity? Would adding deletion change any of the decidability results of this system? 7. What would the performance of the algorithm used in lemma 1 be on the order of? It is decidable, though is it practically implementable? How often do we think that these types of algorithms will be invoked in deployed systems? 8. In figure 6, changing ownership of an object changes the object's label. This in turn changes the permissions associated with the object. Shouldn't there be some way to change ownership without changing the permissions that other users in the system had on the label? NOTES - objects have labels + group labels : Users U is in group with tag G + object labels : User U owns object with tag N - privs + r(l), w(l), x(l): groups who can read, write, execute object labelled l + relabel rules: rl(t, t') is the set of users who can relabel objects with label l \in t to label l' \in t' - native group sets + groups are part of group sets + group membership determined by group labels on group objects - group objects created when a new group is init or when a new user is added - modifying group membership any other ways requires relabel operations on group tags + group sets contain - set of initial group labels of form - New user rule (add new user to group or not?) - Patterns for group membership + specify pairs (with wildcards). Users that match any such pattern are in the group - Admin group set - relabel rules (specify how to relabel group objects) Pros: + They are Able to express a wide range of modesl with simplistic pattern matching + Mapped the model to a useful set of existing DACs, but the list could be longer + 3 level approach + Advances in proving decidable safety properties Cons: - Glossed over the decidability of other models - They didn't really discuss how expressive the model is - How restrictive is the 3 layer model - 1 complete example would have been useful Discussion: Are users alson objects? --- The model doesn't prohibt the users from being objects Section 3.2 was very confusing This could probably be wild carded better, one or all is very restritive Discussion question 1: - OS users would buy layer 1... - How do you know if your implementation is true to the model? - Is it really efficient, implementationwise? Discussion question 6: - The response paper address this... - you could just "go live" again Discussion question 7: - State space gets large - Policy definition time Is this useful? Is my implementation safe? Voting: 2 strong accepts and 7 accepts