The Black Holes of ACLs
Article Date: 2/93
All VOS system administrators and security officers are aware of the need to set up and administer carefully the access control lists (ACLs) for the file system. The access of each user to each file and directory on a disk is controlled by matching the login name of the user against one of the terms in the appropriate ACL (or default ACL - a DACL). What you need to watch out for are the black holes of ACLs where the most carefully planned security scheme can fall in and never be heard from again.
The most obvious problem you can have with an ACL is to make a simple mistake. When you design your ACLs, you must place the most restrictive ACL at the top of the hierarchy for that disk (the pack master level); then you can ease the access restrictions as you move down the tree away from the pack master. This prevents users from giving themselves more access to an object than you want them to have. If Mary_Smith.Finance has only read access to a file in a directory but has modify access to the containing directory, then Mary Smith can give herself write access to the file. By examining the access lists, you can spot that problem and correct it. But you also need to check all the directories higher up the tree, all the way to the pack master. If Mary Smith has modify access at any level above, she can work her way down to this level.
Sometimes ACL problems are not mistakes. This usually comes from interactions with the registration database that may not have been thought of. For instance, you have given Mary_Smith.Finance read access to the file. You have carefully checked the ACLs all the way up to the pack master to make sure Mary cannot alter access rights. So far, so good. However, if Mary can log in to the Test group and *.Test can modify ACLs, you may have another problem. When checking ACLs, it is not sufficient to check the ACL terms themselves. You also must be aware of all the groups that a user can log into and how the access control mechanism will match the user names.
Another kind of ACL problem which is not a mistake involves "superusers". A user who is logged in to the SysAdmin or System group and is privileged can modify access rights on the pack master directory, even if that access is not given in the ACL. Check your registration database to identify who these users are, since they can bypass the access control mechanism. Be especially careful of users who are in the SysAdmin or System group, but not as their primary group. This will not show up if you list users using the registration_admin command.
In addition to identifying holes, don't forget to monitor your VOS security logs for failed access attempts. By consolidating your security incidents and looking for patterns of violations over time, you may uncover attempted abuse before it can be successful.
VOS gives you a powerful method for controlling user access to files and directories by using ACLs. To be effective, however, you need to make sure that they are used in the proper and consistent way. Check the consistency of your ACL terms themselves, and check for consistency with your registered user names. Don't let your security plan fall into a blACL hole!
| 
