|
Top 10 System i Security Q&As
Article courtesy of Search400.com
By Carol Woodbury
Carol Woodbury, System i security expert, has been answering Search400.com's member questions for more than five years. iSeries users have asked Carol the same questions again and again. In an effort to save you time, we've compiled the top 10 questions asked about iSeries/i5 security for you.
TABLE OF CONTENTS
- When auditing is active
- Getting your system to security level 40
- Block an *ALLOBJ user from running a specific command
- Block an *ALLOBJ user by giving special authority to their group
- The authority required to run a specific command
- Exit programs and security requirements
- Give operators access without giving them *ALLOBJ special authority
- Create a read-only profile
- The CHGUSRPRF command doesn't take affect right away
- Password doesn't have to meet the system value(QPWD*) settings
| 1. When auditing is active |
Auditing is only active at security level 40 and 50, right?
No, auditing is active at all security levels. In fact, you want to have auditing turned on to make sure it's safe to move your system to security level 40 or 50.
 Return to Table of Contents
| 2. Getting your system to security level 40 |
How do I move my system to security level 40?
To safely know if you can move your system to security level 40, you need to turn on two types of auditing. To do this, specify *AUTFAIL and *SECURITY in the QAUDLVL system value. Then, you will need to examine the audit journal to determine whether any violations that would prevent you from moving the system to QSECURITY level 40 have occurred. Details on the exact audit journal entries to look for can be found in Chapter 2 of the iSeries Security Reference manual or in my book, Experts' Guide to OS/400 and i5/OS Security, available from Amazon.com.
Return to Table of Contents
| 3. Block an *ALLOBJ user from running a specific command |
Can I block an *ALLOBJ user from running the (insert your favorite command name here) command?
Regardless of the command or API being run, once you give a user *ALLOBJ special authority they can do whatever they want on the system. If even the task requires additional special authorities, all the person has to do is submit the command to run under a profile that has the authority.
Return to Table of Contents
| 4. Block an *ALLOBJ user by giving special authority to their group |
Can't I block an *ALLOBJ user by giving the special authority to their group rather than to the profile itself?
Some people try giving users *ALLOBJ at the group level and blocking individual interfaces at the user level. This effort is fruitless as there are far too many interfaces to attempt to block -- it is a surety that you will miss one. And new interfaces are added each release. So with this approach, you will have to find and consider all new commands and APIs to determine whether or not they should be allowed to run by your *ALLOBJ users. In addition, you have to find all instances of the commands. Many commands exist in more than one library.
Return to Table of Contents
| 5. The authority required to run a specific command |
What authority or special authority is required to run the (insert your favorite command here) command?
The object authorities and any special authorities required to run all CL commands are documented in Appendix D of the iSeries Security Reference manual. The authorities required to run APIs are documented in the individual API documentation, available at the IBM Information Center. In the left navigational bar, choose Programming->APIs then search for the API you are attempting to use.
Return to Table of Contents
| 6. Exit programs and security requirements |
Are exit programs required to secure your system?
No, they are not. What is required is object level security. Unlike attempting to use exit programs to secure your system, object authority is in effect no matter what interface is being used. Exit programs do not provide a complete solution for securing your system or your data. For example, exit programs don't exist to allow to you secure accesses of objects (e.g., files) through sockets or a Web program. Nor are they available when users such as programmers, operators, DBAs, etc access objects through a command line. Exit programs are good for logging network activity such as FTP and ODBC or as an additional layer on top of object security. But they are not a substitute for object security.
Return to Table of Contents
| 7. Give operators access without giving them *ALLOBJ special authority |
How do I give operators or help desk personnel the ability to perform tasks without having to give them *ALLOBJ special authority?
Sometimes the OS/400 helps you out and provides these capabilities for you. For example, one of my favorite utilities is Application Administration, available through iSeries Navigator. One of the things it lets you do is to allow specific users with *JOBCTL special authority to be able to read the joblog of an *ALLOBJ user. To do that, open iSeries Navigator, right-click on the system name, choose Application Administration (at this point it may need to download code to your PC if you've never done this before) then click on the Host Applications tab, open the Operating System/400 tree, open the All object tree click on Access job log of *ALLOBJ user and click the "Customize" button in the lower right hand corner. Here you can choose the users you want to see the *ALLOBJ user joblogs. (For those of you that prefer a green screen interface, this function is available by using the Work with Function Usage (WRKFCNUSG) command, available in V5R3.)
If OS/400 doesn't provide the function you're looking for, I suggest that you write a program that performs the task and adopts its owner's authority (that is, set the User profile attribute of the program to be *OWNER.) Make the program owner be a profile that has sufficient authority and/or the special authorities required to perform the task. For example, I often see this approach used to enable helpdesk personnel or operators to be able to reset user profiles. By calling a program that adopts, they can perform the function but you can avoid giving them authority to all profiles or *SECADM special authority.
Return to Table of Contents
| 8. Create a read-only profile |
How do I create a read-only profile?
You'll find all of the information you're looking for in this "Read-only" tip that I wrote a short while back.
Return to Table of Contents
| 9. The CHGUSRPRF command doesn't take affect right away |
When I change a user's group (using the Change User Profile – CHGUSRPRF command) the change doesn't seem to take affect right away. Why not?
When a user signs on, their special authorities, group profile(s), and limited capability setting are made part of the user's job attributes. Therefore, to have the change take affect, the user must sign off and sign back on again.
Return to Table of Contents
| 10. Password doesn't have to meet the system value (QPWD*) settings |
When an administrator changes a user's password, it doesn't have to meet the system value (QPWD*) settings for password rules. Why not?
The system values that enforce password rules (how short they can be, how often they must be changed, etc) are only checked when going through the Change Password (CHGPWD) command or the change password API. They are not checked when setting the original password through Create User Profile (CRTUSRPRF) or when changing the password through Change User Profile (CHGUSRPRF). This is to facilitate administrators setting the password to an "easy" password. Administrators will use this feature when a user forgets their password, disables their profile and calls in for help. The administrator enables the profile, sets the password to something easy for the user to type in and requires the password to be changed when the user signs on. When the user changes their password, the password system values are checked.
Return to Table of Contents
# # #
Article courtesy of Search400.com
|
