Here is your iSeries security tip for December, 2006 from SkyView
Partners, Inc., World Class i5/OS and OS/400 Security Experts.
I am often surprised when performing a security analysis of a system,
how many profiles’ *PUBLIC authority is not set to *EXCLUDE or the
number of private authorities that have been given to user profiles;
therefore, I thought it might be a good point of this discussion this
month.
Let’s discuss the *PUBLIC authority setting first. When a profile
is created, i5/OS sets the *PUBLIC authority to *EXCLUDE. That’s so
that no other profile on the system can use it (for example, to submit
a job.) Why don’t you want people to be able 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 to give *PUBLIC *READ authority. That way, programmers on call
or the help desk can list out and see the attributes of profiles.
In general, however, profiles should remain with *PUBLIC authority
set to *EXCLUDE.
Another issue that I often see is when users have been given a private
authority to a profile. I’ve seen cases where an over-zealous administrator
had granted himself and all of the programmers *ALL authority to all
profiles on the system! Some users having a private authority to profiles
is a slightly less dangerous scenario than having *PUBLIC authority
be set to *USE or greater but it is still not desirable. 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 there are times when you may choose to give selected users
authority to a profile. The best example is when a profile is named
in 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 option to allow the operators to continue to
use the job description is to grant the system operator group *USE
authority to the profile.
Finally, there are two private authorities that i5/OS grants to profiles
that you should not remove. One is the private authority the profile
has to itself. The authority is *CHANGE plus *OBJMGT. If you remove
this authority, one of the side affects is that profile cannot sign
on the system. Another private authority that shouldn’t be removed
is the private authority a profile has to its group profile(s). This
is *CHANGE plus *OBJMGT minus *EXECUTE authority. Again, unpredictable
sign on and other results may occur when the user is no longer authorized
to its group profile.
Want to know that your system EXACTLY matches your security policy
requirements?
Policy Minder Tip - Ensuring that profiles have the proper *PUBLIC
authority and private authorities is easy with Policy Minder.
Starting
your Christmas list?
You might want to add a 30- day free trial of the newest version of
SkyView Policy Minder to your list!
Policy Minder version 1.2 offers some significant time-saving enhancements
including:
Create templates to discover “new” powerful users.
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 this first screen you define which users to include in
the template. Name the template (I’ll name mine *AUTS), add a description
and then define what profiles are to be examined by the template 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 screen of creating a template. (Some IBM profiles have
private authorities provided by i5/OS 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’m going to stick to only examining the authorities.
So don’t specify anything for the next two screens. Now I’m going
to specify *EXCLUDE for the *PUBLIC authority and *NONE for the private
authority settings. Hit Enter until you return to the Work with User
Profile template screen.
Now that I’ve created my template, I’m going to run a compliance
check. I type SKYVIEWPMP/CHECK CAT ((*USRPRF *AUTS). Now, 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 out of compliance. If any profiles are identified, I’ll review
the results and can 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.
