People don’t need to see information to which they are not authorized. People don’t need to be sabotaging disk drives. Yet at the same time, people do need to be able to get the information they need to do their jobs. Defining a system that allows people to do what they need to do, but no more, is tricky, but it begins with an understanding of the fundamentals of security. This article tells you where to begin and where to look for more information.

In the movie Hoosiers, Gene Hackman stars as Norman Dale, a coach who leads a small-town high school basketball team to the Indiana state championship. What I find most interesting is that Coach Dale accomplishes this by concentrating on fundamentals. He hammers into the players the importance of teamwork. Even though the kids complain that practice is no fun, he forces them to learn to control a basketball and to obey him without question.

There’s a lesson in Hoosiers for all of us. Winning is a result of mastering the fundamentals. A winning security policy for your AS/400 is no different.

I’m writing this article with the assumption that everyone from Acapulco to Zanzibar can access your AS/400. (If your machine is tied to the Internet, that’s true.) No matter who has access to your machine, what fundamentals must you master to maintain the integrity of your software and data?

QSECURITY

Mastery of AS/400 security begins with the QSECURITY system value. This system value has five possible values—10, 20, 30, 40, and 50. As you can see in the table in Figure 1, security level 10 is the least restrictive, and level 50 is the most restrictive. Let’s look at these security levels in more detail.

Security Level 10

At security level 10, any Tom, Dick, or Harry can log into your AS/400. The sign- on screen asks for a user ID, but not for a password. If someone signs on with a user ID for which there is no user profile, the system creates a user profile and presents the main menu. The user can do whatever he likes on the system.

If you type WRKUSRPRF *ALL (work with all user profiles) and press Enter, you will probably see a lot of user profiles. You’ll see BOBBY, BOBBU, BOBBBY, etc., where Bobby mistyped his name signing on upon occasion. You’ll see JACKSMITH, JACK, JSMITH, etc., where Jack Smith couldn’t remember what user ID he had used before.

Security level 10 would be better called insecurity level 10, as it provides no security at all.

Security Level 20

At security level 20, users must sign on with a user ID whose profile already exists on the system and must provide the correct password for that user ID. Once a user is past that hurdle, he can do anything he wants.

The fundamental you need to master at this point is Create User Profile (CRTUSRPRF).

CRTUSRPRF USRPRF(BILL) +

PASSWORD(A99B98C97) +

PWDEXP(*YES) +

INLMNU(ACCTMENU) +

TEXT(‘Bill Lee - Accounting’) +

JOBD(ACCTJOBD)

As users sign on, they’ll have to change their passwords. Here are some guidelines you can provide for your users to help them help you keep a secure system.

• Tell them not to use their names, names of spouses and children, birth dates, or anything else someone might associate with them.

• Tell them to think of something really weird.
• Tell them not to write passwords down in insecure places.
• Tell them not to tape passwords to the bottom of their keyboards.
• Tell them not to tell anyone their passwords. Two other system values are helpful here. QMAXSIGN tells the system how many invalid sign-on attempts to allow from a workstation before taking some specified action. The shipped value is three times. QMAXSGNACN tells the system what action to take when the maximum number of invalid sign-on attempts is reached.

The shipped value, three, varies off the workstation and disables the user profile that was entered. (For a more in-depth look at the various system values that control password creation, see “System Security Values Demystified” in this issue of Midrange Computing.)

Security Level 30

Level 30 is the minimum adequate security level. There may be legitimate reasons a production AS/400 should run at 10 or 20, but I can’t think of any.

At security level 30, users must sign on with an acceptable user ID and password. Once a user is signed on, he can access only the resources to which he is authorized.

“Resources” can be a lot of things, but the typical data processing shop concentrates on two object types—programs and files. The security administrator can tell the system that DICK is the only one allowed to run program XYZ. The security administrator can tell the system to let BILL modify the customer master file, to let SAM

read the customer master file, and not to let CHARLEY access the customer master file at all. Even if SAM brings his cousin, an AS/400 programmer/analyst and DFU wizard, into the office one Saturday morning, he won’t be able to change the customer master file or run program XYZ.

Types of Authority

You can give different users different authorities to an object. There are 10 basic authorities you can grant, and you can grant as many or as few as you choose. Five of these authorities are called object authorities, and five are called data authorities.

These are the object authorities:
• *OBJOPR (object operational). The user can view the description and has data authorities to the object.

• *OBJMGT (object management). The user can control security for the object, move the object, and rename the object. If the object is a database file, the user can add file members.

• *OBJEXIST (object existence). The user can control the existence and ownership of an object.

• *OBJALTER (object alter). The user can alter the attributes of an object.
• *OBJREF (object reference). The user can use the authority of one object in reference to another object. (This sounds confusing, but you can find a clear example in the CL Reference manual, under discussion of the Grant Object Authority (GRTOBJAUT) command.) If a user has *OBJREF authority to a physical file, he can add referential constraints in which the file is the parent.

These are the data authorities:
• *READ. The user can retrieve the contents of an entry in an object.
• *ADD. The user can add entries to an object.
• *UPD (update). The user can change the entries in an object.
• *DLT (delete). The user can remove entries from an object.
• *EXECUTE. The user can run a program or locate an object. Rather than grant several individual authorities to a user, you can instead use the aggregate values *ALL, *CHANGE, and *USE. The left side of Figure 2 (labeled GRTOBJAUT) shows the specific object and data authorities that correspond to these values.

You can also use the value *EXCLUDE, which means the user has no authority to the object, and *AUTL, which means the object authorities are determined by an authorization list. I’ll return to the subject of authorization lists later.

Granting and Revoking Authority

To give a user authority to an object, run the GRTOBJAUT command. For instance, to allow BILL to modify the customer master file, do this:

GRTOBJAUT OBJ(HOLT/CUSTMAS) +

OBJTYPE(*FILE) USER(BILL) +

AUT(*CHANGE)

The system will respond with the message “Object authority granted.” To keep a user from accessing an object, specify AUT(*EXCLUDE). For example, to keep CHARLEY out of the customer master file, do this:

GRTOBJAUT OBJ(HOLT/CUSTMAS) +

OBJTYPE(*FILE) USER(CHARLEY) +

AUT(*EXCLUDE)

Again, the system responds with “Object authority granted.” That message always strikes me as strange, since authority was taken away, not given, but it just means the system did what you asked it to do.

If you prefer, you can use the Edit Object Authority (EDTOBJAUT) command or option 2 on the Work with Objects (WRKOBJ) display.

If you’d like to view the authorities of an object, use Display Object Authority (DSPOBJ-AUT) or option 5 on the WRKOBJ screen. You’ll see a screen like that in Figure 3. If a user has object or data authorities not covered by one of the aggregate values, you’ll see the term USER DEF in the object authority column. To see the specific authorities, press the F11 key.

Since the introduction of the Integrated File System (IFS), OS/400 has had two other commands for working with authority—Work with Authority (WRKAUT) and Change Authority (CHGAUT). You can use these commands for objects in the library system if you prefer, but you have to specify object names in IFS format. You must use these commands for objects in the other file systems. The authority values are UNIX-like. That is, the authorities granted are known as “read,” “write,” and “execute” privileges. The right side of Figure 2 (labeled CHGAUT) shows the object and data authorities that correspond to the permitted values.

I prefer to use EDTOBJAUT when working with the library file system. I think you’ll find it easier to use, and it allows you to specify operational authorities that CHGAUT does not.

So, you have 125 physical files, 1030 programs, 8 OUTQs, 17 data areas, 6 libraries, 4 job queues, and 16 users. Does this mean, then, that you need to run GRTOBJAUT 1,940 times or more? Not at all! OS/400 has provided you with some shortcuts to make this task easier.

*PUBLIC Authority

First, consider what authority the general public should have. I don’t mean the people on the street, but authorized users of your AS/400. *PUBLIC is a special value for a user profile. It means anyone not listed in the object authorities.

If you have an OUTQ called PRT01 that everybody should be able to freely use, grant *CHANGE authority to *PUBLIC.

GRTOBJAUT OBJ(HOLT/PRT01) +

OBJTYPE(*OUTQ) +

USER(*PUBLIC)

Notice I didn’t use the AUT parameter. You don’t have to specify it in this case because the default value is *CHANGE.

To remove a user’s private authority to an object, use the Revoke Object Authority (RVKOBJAUT) command. This is somewhat of a misnomer, too. It sounds as if a user no longer has authority to an object, but that’s not necessarily true.

For instance, let’s say you no longer want BILL to have special access to the customer master file.

RVKOBJAUT OBJ(HOLT/CUSTMAS) +

OBJTYPE(*FILE) USER(BILL) +

AUT(*CHANGE)

The system will respond, “Object authority revoked.” Bill now has *PUBLIC authority.

Group Profiles

Group profiles are user profiles, but users don’t use them for signing on to the system. Instead, the group profiles define authorities for the users in the group.

For instance, suppose your sales department consists of three people, with user IDs of LARRY, CURLY, and MOE. Let’s suppose that all three need the same access to objects. You could create a group profile called SALES:

CRTUSRPRF USRPRF(SALES) +

PASSWORD(*NONE) +

TEXT(‘Sales department’)

You’d assign the three users to that group profile. Here’s Larry:

CHGUSRPRF USRPRF(LARRY) +

GRPPRF(SALES) +

OWNER(*GRPPRF)

You’d need to grant or revoke object authority to SALES. Here’s an example:

GRTOBJAUT OBJ(HOLT/CUSTMAS) +

OBJTYPE(*FILE) +

USER(SALES) +

AUT(*CHANGE)

Instead of three private authorities to CUSTMAS, you now have only one. So, group profiles provide a way to group users with common security requirements. What about a way to group objects with common security requirements? I’m glad you asked!

Authorization Lists

An authorization list is a list of users and authorities. For example, SUE might have *CHANGE authority, while BECKY has *USE authority. The authorization list does not answer the question, “To what objects are they authorized?”

To do that, you have to attach the authorization list to objects. Specify the authorization list name in the EDTOBJAUT screen, just under the screen headings and above the private authorities.

To create an authorization list, use the Create Authority List (CRTAUTL) command. The authorization list will be created in library QSYS, as an object of type *AUTL.

Special Authorities

You should get to know a couple of other parameters of the CRTUSRPRF command. One of them is SPCAUT (special authorities).

Figure 4 shows the permissible values for this parameter. You can grant more than one value to a user.

The default value is *USRCLS, which means that the special authorities granted are those you would normally grant to the type of user specified in the USRCLS parameter when you create the user profile. Which authorities are granted to the various classes depends on the release of OS/400 running on the machine.

User Profile Classes

The other parameter of CRTUSRPRF you need to know about it USRCLS. The defined types of users are shown in Figure 5.

These classes do not always allow a shop to function as it should. Programmers typically need *JOBCTL, *SPLCTL, and *SAVSYS authorities, for example. End users may need *SPLCTL authority to start the printers in their offices. You can use the CHGUSRPRF command to grant special authorities to those who need them, or you can provide users with programs that adopt authority to enable them to do the tasks they need to do. (See “Object Security by Adoption” in this issue of MC.)

Security Levels 40 and 50

Security level 40 prevents programs from circumventing normal security measures by requiring them to access objects in approved ways. “Approved ways” means the language features designed to access objects. Examples of approved interfaces are the CL RTVxxx commands; the RPG I/O operations like OPEN, READ, and UPDAT; and the various APIs that retrieve or change objects. However, a C program that uses pointer variables to access the internals of an object does not adhere to approved interfaces and would be stopped by security level 40.

Security level 40 also plugs a few holes in level 30. For example, with level 30, a user can submit a batch job without having *USE authority to the user profile specified in the submitted job’s job description. Level 40 does not allow this.

Level 40 does these things:
• Prevents the use of unsupported interfaces
• Prevents the use of restricted instructions
• Protects job descriptions
• Prevents signing on without a password
• Provides enhanced hardware storage protection
• Protects a program’s associated space
• Protects a job’s address space
• Validates that programs being restored do not use restricted instructions Security level 50 adheres to the C2 requirements established by the U. S. Department of Defense. Level 50 adds a little more protection to an AS/400, but at the cost of degraded performance. Unless you are required to meet C2 requirements, you probably should not run at level 50.

The Audit Journal QAUDJRN

If you wish, OS/400 can gather security information and store it for you in journal QSYS/QAUDJRN. With this tool, you can audit users and objects.

To use this feature, you need to become familiar with three CL commands. I’ll hit the high points, but you really need to spend some time in the CL Reference getting more familiar with them.

Use the Change Security Auditing (CHGSECAUD) command to set up auditing. CHGSECAUD changes the QAUDCTL and QAUDLVL system values and creates the QAUDJRN journal if necessary. Set the QAUDCTL parameter to *ALL.

Use the Change User Audit (CHGUSR-AUD) command to start auditing for a user. Some of the things the system can track include the following:

• Creation, deletion, and management of objects by the user
• Job start and stop
• Use of programs that adopt authority
• Save and restore operations
• Security changes
• Spool file operations
• Use of CL commands, S/36 environment operator control commands, and S/36 procedures

Use the Change Object Auditing (CHGOBJAUD) command to audit objects. On the OBJAUD parameter, you can tell the system to log all changes, all reads and changes, or accesses for certain users only.

Once the journal starts collecting data, you can build reports and queries by using the Display Journal (DSPJRN) command or any tools you have for working with journaled data.

Moving to Security Level 40

Security level 40 is probably the best level for most shops and, in fact, is what all new AS/400s are shipped at. It provides adequate security for all but the most stringent of requirements, and it provides better performance than security level 50.

Here’s a good place to start mastering the fundamentals. If you’re running at anything less than 40, you should consider moving to 40. First, though, make sure that the software you’re running will run under level 40. If it won’t, maybe you should ask your software provider why not. (See “Security Patrol” in this issue of Midrange Computing for a more in-depth look at why your software may not run under security level 40.)

Once you’re sure that changing to security level 40 isn’t going to halt production, type the Work with System Value (WRKSYSVAL) command and press Enter. Choose option 2 (change). Enter the value 40 and press Enter.

You’ll have to IPL to make the change in system value take effect.

Safe and Secure

Security is not something you can do once and then forget about. From time to time, you should reexamine your security policy to make sure it’s still adequate. Run the command WRKSYSVAL SYSVAL(*SEC) OUTPUT(*PRINT) to get a listing of all security-related system values. Compare them to the shipped values, and make sure any discrepancies you find are ones that you actually want to be there.

By the way, if you decide to watch Hoosiers, let me recommend the version we have, the one from Feature Films for Families. All the profanity has been removed. There are certain fundamentals I don’t want my kids to master.

References

AS/400 Advanced Series Security—Basic (SC41-4301, CD-ROM QBJALB00) AS/400 Advanced Series Security—Reference (SC41-4302, CD-ROM QBJALC01)

CL Reference (SC41-4723, CD-ROM QBJAUP01)

10 No security Anyone can sign on to the system. 20 Password required Anyone with a user ID has unrestricted access to the system. 30 Resource security enabled Users have access only to the resources to which they are allowed.
40 Integrity protection Access to resources is permitted only through approved interfaces.
50 Enhanced integrity protection An overly restrictive version of level 40.

Figure 1: Permissible values of system value QSECURITY

GRTOBJAUT CHGAUT

*ALL *CHANGE *USE *RWX *RW *RX *R *WX *W *X *OBJOPR x x x x x x x x x x *OBJMGT x n/a n/a n/a n/a n/a n/a n/a *OBJEXIST x n/a n/a n/a n/a n/a n/a n/a *OBJALTER x n/a n/a n/a n/a n/a n/a n/a *OBJREF x n/a n/a n/a n/a n/a n/a n/a *READ x x x x x x x
*ADD x x x x x X
*UPD x x x x x x
*DLT x x x x x x *EXECUTE x x x x x x x

Figure 2: A summary of authorities Figure 3: The DSPOBJAUT display shows authorities by user

*ALLOBJ The user can use all objects on the system, regardless of private authorities. *SECADM The user has authority to user profiles.
*IOSYSCFG The user can configure input/output devices.
*JOBCTL The user has authority to jobs, writers, and subsystems.

Ted Holt is IT manager of Manufacturing Systems Development for Day-Brite Capri Omega, a manufacturer of lighting fixtures in Tupelo, Mississippi. He has worked in the information processing industry since 1981 and is the author or co-author of seven books. 

---

MC Press books written by Ted Holt available now on the MC Press Bookstore.

		Complete CL: Fifth Edition Become a CL guru and fully leverage the abilities of your system. List Price $79.95 Now On Sale
		Complete CL: Sixth Edition Now fully updated! Get the master guide to Control Language programming. List Price $79.95 Now On Sale
		IBM i5/iSeries Primer Check out the ultimate resource and “must-have” guide for every professional working with the i5/iSeries. List Price $99.95 Now On Sale
		Qshell for iSeries Check out this Unix-style shell and utilities command interface for OS/400. List Price $79.95 Now On Sale

Also Read

Sharing Securely: How to Cope, Part 1

Artificial Intelligence and Cybersecurity

AIX Security Basics eCourse