Welcome to the introduction of a new MC monthly feature. In each issue, this column will discuss short security topics, cover implementation tips and answer security questions relating to the AS/400. I welcome your questions, recommendations and suggestions for security topics you would like discussed in detail in future issues. I can be reached using the MC OpenBBS at (619) 931- 9909 or by fax at (507) 252-9615. While I cannot answer every question in this column, I will try to answer those questions of a general nature.
Please include your phone number and indicate if your name can be published with the questions or recommendations. Security, like life, is a series of choices-you must evaluate the recommendations from this column as they apply to your installation. Chief of Security: Wayne O. Evans.
Q: Do you see anything wrong with analysts being able to browse the contents of the *USRPRF object type? Since they cannot see the password, I don't see any problem with them doing this. To go one step further and make our job of giving them this access easy, I'd like to change the Create User Profile (CRTUSRPRF) command so that when it adds a user, it also sets PUBLIC with *USE authority. Thus, anyone will be able to browse any other user's profile. What do you think about allowing everyone to see anyone else's user profile?
A:Viewing other users' profiles is not generally an exposure. However, I do not recommend giving *PUBLIC authority of *USE to user profiles. This enables others to view the profile but it also allows a them to submit a job to run as the other user. If user FRED has *USE access to the MARY user profile, then FRED can use the Submit Job (SBMJOB) command to run jobs as the user MARY, as follows:
SBMJOB USER(MARY) CMD(any operation allowed by user MARY)
If users are allowed to run jobs as other users, this removes individual accountability. Granting *USE authority to a user profile is equivalent to giving the password of the user away for submission of jobs in batch.
If you want to allow programmers to view user profiles, I would create a CL program that adopts the security officer's profile to display user profiles. The Create CL Program (CRTCLPGM) statement used to create the CL program must specify USER(*OWNER) and the owner of the program should be a user that has *ALLOBJ special authority. When the program is called, the user is prompted for the name of the user profile to display. This program eliminates the need to grant users access to other user profiles when the program adopts the authority of an *ALLOBJ user such as QSECOFR. See 1.
If you want to allow programmers to view user profiles, I would create a CL program that adopts the security officer's profile to display user profiles. The Create CL Program (CRTCLPGM) statement used to create the CL program must specify USER(*OWNER) and the owner of the program should be a user that has *ALLOBJ special authority. When the program is called, the user is prompted for the name of the user profile to display. This program eliminates the need to grant users access to other user profiles when the program adopts the authority of an *ALLOBJ user such as QSECOFR. See Figure 1.
Q:If I give a user *ALL authority, is that the same as making the user the owner? What is the difference between being the owner of an object or a user with *ALL authority?
A:For most operations, there is no difference between a user that is the object owner and a user with *ALL authority. The object owner has two additional functions.
1) When you are the owner of an object, you can revoke your authority to less than *ALL access and you can always grant back any authority that has been revoked. For example, the owner could remove *OBJEXIST authority to prevent accidental deletion of critical objects. The owner can still delete the object by granting back *OBJEXIST authority and then delete the object. However, if a user with *ALL authority who is not the object owner revokes his own authority, that user cannot grant back authority which has been revoked.
2) Space for an object is allocated to the object owner's user profile. The object owner's profile cannot be deleted when the user profile owns objects. Space is not allocated to users that are not the object owner. User profiles that are authorized to objects can be deleted as long as those profiles own no objects. Deletion of the user profile automatically cleans up all authorizations.
Security Patrol: Security Questions & Answers
Figure 1 A Safer Way to Display a User Profile
/*===============================================================*/ /* To compile: */ /* */ /* Sign on as a user with *ALLOBJ special authority */ /* */ /* CRTCLPGM PGM(XXX/DSPUSRPRFA) SRCFILE(XXX/QCLSRC) +*/ /* USRPRF(*OWNER) */ /* */ /*===============================================================*/ DSPUSRPRFA: PGM DSPUSRPRF ??USRPRF(*N) ENDPGM