On Wed, Aug 21, 2002 at 03:05:20PM -0500, Tom Hart wrote: > Lionel Elie Mamane wrote: >>On Wed, Aug 21, 2002 at 11:29:04AM -0500, Tom Hart wrote: >>> The one thing about NT's approach that I think is good is the >>> presence of Deny ACEs. >> I feel like one can't have Deny ACEs without order dependency. And >> that is a bad thing. > I'm thinking a Deny ACE automatically overrides any Allow ACE, but > with no inheritance. > there is no need for order dependency. > Am I missing something here? No, if you take it that way, no order dependency. >> I can't come up with a sensible scenario where Deny ACEs make >> sense, where they really make things better for the user, or the >> administrator or ... You think you can: >>> And I suspect that there are many situations in which it would be >>> more convenient to add a Deny ACE to a file than to have to make a >>> new group that excludes the person to whom you'd like to deny >>> access. >> I'm curious to hear about such a scenario. With all examples that >> pop-up in my head, using Deny ACEs actually would be an example of >> bad administration, or rules that won't hold the passage of >> time. It all revolves around "why do you want to exclude this one >> person"? I don't see any reason that would apply to one person and >> NEVER to a new member of the group. If you give access to group G, >> and user U is in G, but you don't want to give access to group G, >> then either: >> - G is not the right group you want to give access to. >> - U does not belong in G. Fix _that_. >> E.g., if you are member of the board of the Big A Corp., and you >> are plotting to throw the chairman out. You don't want the chairman >> to be able to read your plans, OK. But then giving access to board >> member, and a Deny ACE for the chairman is not the right answer: >> You want that only plotters access the plans. If a new board >> members is accepted, you don't want him to automatically have >> access to the plans: he might be the chairman's pawn. > Ok, continuing with your example: I'm a plotter. The sysadmin gives > all employees and board members access to set permissions on their > own files, but not to create new groups. Furthermore, the sysadmin > has more important things to do than make a group for people I > trust. > Hence the only way I can block the chairman is with a Deny ACE, or > by removing the "Allow access to group board" ACE, and explicitly > adding ACEs for all the plotters. > True, this leaves me open to my adversary employing an agent. But > creating a new group may not always be possible. As you say yourself, permission to board + deny to chairman leaves you open to an attack. So why would you use that solution? Any (computer literate) sensible person would use an explicit ACL entry for each plotter. That scenario doesn't hold. > Also, Deny ACEs become more interesting in the context of groups, I > think, since they correspond to the set difference operation. For > example, take the groups "Students" and "Untrusted Students". Using > an Allow ACE for Students and a Deny ACE for Untrusted Students > amounts to having an Allow ACE for the group "Trusted Students" > (without explicitly creating this group). Why the hell have you created "Untrusted Students" in the first place? If you have created that group, you already think in a "Deny ACE" way. If, at group creation time, you keep in mind that a group is used only to give additional rights, not to remove them, you would have created "Students" and "Trusted Students". My point is that if your system does not support Deny ACEs, (with a good admin), you wouldn't end up in this situation: He would have never created the group "Untrusted Students", because it is useless. In short: With some brain power at group creation time, you can create the right groups in order to never have to use set difference, only set union. This does not increase the number of groups to create, it only changes *which* groups you create. More deeply, I think that with access control, you shouldn't even think substractively. Think additively. It is always possible, and IMHO cleaner. > Perhaps the system could keep track of "Virtual Groups" somehow; Again, with some care at group creation time, you don't need Virtual Groups that are set difference of two other groups. The only case I see is when, in an heterogenous environment, the "first" system to be deployed was a system supporting Deny ACEs. So, it is full of groups like "Untrusted Students". Now, you start installing GNU/Hurd systems, and you want the users / groups database to be shared with the other system. But with this kind of argument, you end up adding to you system any feature any other system has, even if it is very brain-dead. -- Lionel
Attachment:
pgpQn1lbFWO4E.pgp
Description: PGP signature