The Four Hundred

It's unfortunate that the finer points of OS/400 security checking are sometimes missed. For example, OS/400 object authority verification can involve as many as seven different authority checks against individual user profiles, associated group profiles, and public authority (*PUBLIC) before providing object access. These checks can significantly impact your security scheme, determining whether you've totally locked down security or left a hole or two open.

As most system administrators know, OS/400 object authority can be set by using the green-screen Edit Object Authority (EDTOBJAUT) command or by setting permissions for an object within the iSeries or the Client Access Operations Navigator program. Using these functions, you can set authorities for object-level access (whether a user can use, change, or delete an entire object) or data-level access (whether a user can read, add, change, or delete individual records in an object).

When a user requests an object, OS/400 processes up to seven levels of object-authority checking as it decides whether to allow access. It does this in a specific sequence, by first checking the individual user profile for proper authority, then any group profile with which the user is associated. If no match is found in the first group of checks, OS/400 finally checks any *PUBLIC authorities that may affect the request.

Here is a list of the seven object-authority checks OS/400 makes as it determines whether a user profile has authority to an object. Once OS/400 finds a match, object-authority checking stops and access is either granted or denied.

OS/400 first checks whether the user profile attached to the request has implicit or explicit authority to the requested object. When checking for individual user profile authority, OS/400 looks at the following items:

1. Does the requesting user have all-object (*ALLOBJ) authority associated with its user profile? The *ALLOBJ authority trumps everything else; if the user profile has it, there is almost nothing inside native OS/400 that that user cannot reach. This is the reason why many security experts recommend being extremely stingy in handing out *ALLOBJ authority. Giving *ALLOBJ authority to a user profile is like giving the master key to your entire iSeries or AS/400 box. You don't want everyone to have it.

2. Does the requesting user profile have individual private authority to the object? An entry in the object's private authority list explicitly states whether the user has authority to perform the requested operation on the object.

3. Is the user granted proper authority through an entry in an external authorization list (object type AUTL) that is attached to the object? Authorization lists are created and maintained through the green-screen Work with Authorization Lists (WRKAUTL) command or through OpsNav, and a single list can be assigned to several objects. Once an authorization list is assigned to an object, any permission specified in that list is automatically applied to the object.

If OS/400 finds permission for the requesting user profile in checks 1 through 3, object-authority checking stops and access is either granted or denied.

If there are no explicit permissions assigned to the user through *ALLOBJ authority, private-object authority, or an authorization list (checks 1 through 3), OS/400 next checks any group profile that the user belongs to, in order to determine whether an associated group profile has explicit authority to the object. If a match is found, the user adopts the same authority to access that object as any of its associated group profiles. OS/400 checks the user's associated group profiles to determine whether the user can access the object as requested:

4. Does an associated group profile have *ALLOBJ authority? If so, like an individual user profile, the group profile has access to almost everything in OS/400 and the user is allowed to access the object. Note again, however, that providing *ALLOBJ to a group profile is not in the best interests of your security scheme.

5. Does an associated group profile have private authority to the object, as specified in the object's private authorities? If so, access is granted or denied based on the group profile's explicit authority to the object.

6. Does an associated group profile have authority to use the object through an external authorization list attached to the object? Since the user adopts the authority of its associated group profiles, it will be granted or denied access if one of those profiles is specified in an authorization list assigned to that object.

Checking object authority through associated group profiles is pretty much the same as authority checking for individual user profiles. The user profile adopts the authority of its associated group, and access is granted or denied based on that group profile's authority.

If all else fails and OS/400 can't find a valid permission in the individual user profile or its associated group profiles, OS/400 performs the following check against the object:

7. Does the object's *PUBLIC authority have sufficient authority to grant or deny the user access to the object? The *PUBLIC authority is an object's catch-all authority. It tells OS/400 whether it should grant access to the target object to anyone not specifically covered under one of the other authorities.

Once you understand how OS/400 checks authority, you can manipulate object-authority checking to your advantage. For example, these checks illustrate how important it is to limit *ALLOBJ authority to only those users who truly need it. Since *ALLOBJ authority opens the authorization door in two object authority checking levels (checks 1 and 4), overusing *ALLOBJ authority can severely weaken your system's security.

These checks also speak to the importance of *PUBLIC authority. Since *PUBLIC authority checking kicks in when a user or its associated group profiles aren't explicitly mentioned in an object's authority-checking scheme, it's important to limit *PUBLIC authority.

Finally, this checking scheme makes a case for granting permissions on the group-profile level, rather than on the individual-user-profile level. Not only is it easier to control a system when you're assigning permissions once to several users who use the same group profile, it also provides an out if you need to limit access for one user in the group. For example, if I were to specify that all users who used the MS_GRP group profile could access object A, and user 1 was a member of MS_GRP, I could stop user 1 from accessing object A, by specifying that he is excluded from using the object (*EXCLUDE) inside object A's private authority list. Because individual user profile private authority checking (check 2) is performed before group profile private authority checking (check 5), OS/400 would deny him access even though he's associated with a group profile that has access.

So the object-authority game can be played several different ways, but the key lies in knowing the authority-checking rules.