When I perform a security analysis of a system, I'm often surprised by how many profiles' *PUBLIC authority is not set to *EXCLUDE or how many private authorities have been given to user profiles.
Let's discuss the *PUBLIC authority setting. When a profile is created, i5/OS sets the *PUBLIC authority to *EXCLUDE so that no other profile can use it (for example, to submit a job). Why don't you want people to use profiles other than their own? So they can't masquerade as another user! The only *PUBLIC authority setting that may be acceptable in certain situations is *PUBLIC *READ authority. That way, programmers on call or the help desk can see the profiles' attributes. Generally, however, profiles should remain with *PUBLIC authority set to *EXCLUDE.
Another problem I often see is that users are given private authority to a profile. In some cases, overzealous administrators grant themselves and all the programmers *ALL authority to all profiles on the system! Allowing some users private authority to profiles is slightly less dangerous than setting *PUBLIC authority to *USE or greater, but it's still undesirable. The danger rises with the power of the profile. Granting authority to a profile with all special authorities allows all users with that authority to submit jobs running as the profile with *ALLOBJ. Auditing the use or exploitation of this authority becomes very difficult.
However, sometimes you may choose to give selected users authority to a profile—for example, when a profile is named in a job description and the system operators need to use this job description to submit jobs. (The need for this authority is often identified when trying to move from a lower security level to security level 40 or 50.) In this case, one way to allow the operators to continue to use the job description is to grant the system operator group *USE authority to the profile.
Finally, i5/OS grants to profiles two private authorities that you should not remove. One is the private authority the profile has to itself—*CHANGE plus *OBJMGT. If you remove this authority, one effect is that the profile cannot sign on to the system. Another private authority that shouldn't be removed is the private authority a profile has to its group profile(s)—*CHANGE plus *OBJMGT minus *EXECUTE. Again, unpredictable sign on and other results may occur when the user is no longer authorized to the group profile.
Ensuring that profiles have the proper *PUBLIC authority and private authorities is easy with SkyView's Policy Minder.
From the main menu, take option 1 (Work with Policies). Take option 5 on the *USRPRF category. Press F6 (Create) to create a new user-profile template. On the first screen, define which users to include in the template. Name the template (I'll name mine *AUTS), add a description, and define what profiles the template is to examine on a compliance check. You can include all profiles on the system or a subset of the profiles. For this example, I'll include all profiles except the IBM profiles by specifying I *ALL *USRPRF and O Q* *USRPRF on the first template definition screen. (Some IBM profiles have i5/OS-provided private authorities, and others don't have *EXCLUDE for the *PUBLIC authority, so I'm going to exclude IBM profiles. I may choose to put those in their own template later.)
Scroll down. You can specify to examine other attributes of the profiles, but for this example, I'll examine only the authorities, so I won't specify anything for the next two screens. Now, I specify *EXCLUDE for the *PUBLIC authority and *NONE for the private authority settings. Then, I hit Enter until I return to the Work with User Profile template screen.
Now that I've created my template, I'll run a compliance check. I type SKYVIEWPMP/CHECK CAT((*USRPRF *AUTS). Any profile that isn't owned by the profile UPOWNER, doesn't have *PUBLIC authority of *EXCLUDE, or has private authorities assigned to it will be flagged as being non-compliant. If any profiles are identified, I'll review the results and use the FixIt function to change the authorities.
What about the private authority a profile has to itself and the group profile authorities? Policy Minder accounts for those. While they will be listed on a compliance report, they won't cause the profile to be out of compliance—even if you have specified *NONE for the private authority setting.
This is just one thing SkyView Policy Minder can do for you. For more information or a 30-day free trial, visit skyviewpartners.com. And see Skyview's other offerings in the MC Showcase Buyer's Guide.
Carol Woodbury is president and co-founder of SkyView Partners Inc., a company specializing in security policy and compliance software and services. Carol is a system security expert, a noted author, and an award-winning presenter. Along with Pat Botz, Carol is the author of Experts’ Guide to OS/400 & i5/OS Security.
Partner TechTip: Authorities to User Profiles
Typography
- Smaller Small Medium Big Bigger
- Default Helvetica Segoe Georgia Times
- Reading Mode
LATEST COMMENTS
MC Press Online