The danger of indiscriminately assigning special authorities

This article explains the special authorities and points out the main exposures if they are not assigned judiciously.

You Can View User Feedback To This Tip

A few months ago as I was perusing the iSeries Internet newsgroup (news://comp.sys.ibm.as400.misc) I was surprised to see a reference to solving spooled file control problems by assigning *SPLCTL (Spool Control) special authority to several end users. I quickly fired back my response saying that granting *SPLCTL special authority makes the user the god of all spooled files on the system, and that sensitive and private information could be compromised.

Special authorities are just that ... special. They are not object-level authorities that determine what files or programs you can access and manipulate. Instead, they provide the ability to perform certain operational and administrative functions on the iSeries. This article explains the special authorities and points out the main exposures if they are not assigned judiciously.

Assigning special authorities

When you create or change a user profile, one thing that happens is that you implicitly or explicitly assign special authorities to the user profile. When you assign a user to a User Class (e.g. *SYSOPR, *USER, *PGMR) you also assig a set of default special authorities to the user. Those defaults are determined by the User Class you assign. For the sake of brevity, I will assume you are running system Security Level 30 or higher. The chart below shows the default special authorities assigned to each User Class.

User Class Default Special Authorities

*SECOFR All Special authorities *SECADM *SECADM *PGMR None *SYSOPR *JOBCTL and *SAVSYS *USER None

If you decide that the default special authorities for a user are not what you want, you may explicitly assign special authorities using the SPCAUT parameter of the CRTUSRPRF(Create user profile) and CHGUSRPRF(Change User Profile) commands.

How to determine who has special authorities

The PRTUSRPRF (Print User Profile) command can be used to print a list of all special authorities held by each user profile. To generate the complete list, use the command:

PRTUSRPRF  TYPE(*ALL)   SELECT(*SPCAUT)   SPCAUT(*ALL)

Any special authorities held by the user are marked with an X under the special authority they hold.

 

But before you assign any of these special authorities, you need to understand them. Let's review each one.

*SPLCTL Special Authority

What is it?
Spool Control. Maybe the most misunderstood, *SPLCTL makes the user the god of all spooled files on your system. In fact, as the name spool control indicates, a user with *SPLCTL can control all system spooling functions. This includes controlling not only output queues, but job queues as well. The user may hold, release and clear job queues and output queues, even if they are not authorized to those queues.

What are the main exposures?
*SPLCTL allows the user to view and manipulate ANY spooled file on the system, even if they reside in a secured output queue. So, even your most confidential reports are wide open to the user.

*ALLOBJ Special Authority

What is it?
This is the biggy. All Object Authority. *ALLOBJ grants the authority to manipulate any object on the system, with the exception of User Profiles, for which *SECADM special authority is required. *ALLOBJ also allows the user to assign object level authorities, regardless of the authority already placed on the object.

What are the main exposures?
Every file, program, data area, etc on your system is open to access, manipulation and even deletion. Delete the Payroll library ... Sure, with *ALLOBJ.

A user with *ALLOBJ, can submit a batch job that specifies another powerful user profile to accomplish ANY system function. So, for example, even if you don't assign *SECADM special authority to a user that has *ALLOBJ, that user can still submit a batch job using a profile that does have *SECADM and create and manipulate user profiles.

*SECADM Special Authority

What is it?
Security Administrator. *SECADM special authority provides the ability to maintain user profiles. When creating or changing profiles, the *SECADM cannot assign special authorities that they do not possess. It's like having a head cold: You can't give it to someone else if you don't have it. There's one caveat, only if the user has *ALLOBJ and *SECADM can the user assign *SECADM to another profile.

*SECADM does not provide the ability to change user profiles that the user does not have authority to. For instance, a user with *SECADM typically will not be able to change the QSECOFR password, unless they also have *ALLOBJ special authority.

What are the main exposures?
A user with *SECADM can create and change user profiles at will. You need to insure that the user understands your system security policies regarding user profiles. As a further step, you will want to audit user profile creation and changes to verify compliance.

*JOBCTL Special Authority

What is it?
Job Control. Many folks are fooled into thinking that this special authority is only about controlling jobs, as the name certainly implies. In fact, *JOBCTL not only provides the capability to control jobs, but also to control spooled files and printers. With *JOBCTL you can even control subsystems (Start, End) and Power down the system.

In the area of spooled file control, JOBCTL is almost as powerful as SPLCTL, but not quite. With JOBCTL, any output queue to be controlled by the user must have been created with the OPRCTL attribute set to YES. In effect, you can prevent a user with JOBCTL from manipulating an output queue by creating it with OPRCTL(*NO).

When it comes to controlling jobs, a user with *JOBCTL can change the attributes of a job -- and can even force a job to end.

What are the main exposures?
The power of JOBCTL can be used to Power down the system or to terminate subsystems or individual jobs during critical operational periods. If output queues are OPRCTL(YES), the user may view ANY sensitive spooled file.

*SAVSYS Special Authority

What is it?
Save System. This special authority allows the user to backup and restore objects. The user need not have authority to view the objects. This special authority is required to run nightly and weekly backups of the system. *SAVSYS is usually reserved to the system security officer and system operator.

What are the main exposures?
A user with *SAVSYS can save objects to tape and load that tape on another iSeries machine to view the contents of sensitive data files. The user may also save objects to tape and then view the information using the DSPTAP or DMPTAP commands. Save and restore operations should be under system audit control, and tape media must be strictly controlled.

*SERVICE Special Authority

What is it?
Service. *SERVICE special authority provides the user with the ability to run the system services tools (STRSST) and to debug programs to which they have only *USE authority. The system services tools include the ability to trace various systems functions and to access the Display /Alter/Dump functions. These service tools need to be very tightly controlled, and typically they aren't assigned to any profile, except the system security officer.

What are the main exposures?
The exposures here are numerous. Here are few of the main ones. Using the communication trace function of the system service tools, the user may see the data stream flowing between the PC clients and the host. This data includes user ids and any unencrypted passwords. Using the Display/Alter/Dump functions, object code and other data can be viewed and even manipulated.

*IOSYSCFG Special Authority

What is it?
I/O System configuration. *IOSYSCFG provides the ability to configure and change the system communication configuration (e.g. lines, controllers, devices), including the system's TCP/IP and Internet connection information.

What are the main exposures?
System communications are a highly technical area of systems management and control. Insure that any user having *IOSYSCFG has the technical expertise to set up your communications correctly and securely. For example, a misconfigured Internet service like Hypertext Transport Protocol (HTTP) can open wide holes in your system security.

*AUDIT Special Authority

What is it?
Audit. *AUDIT special authority puts the user in control of the system auditing functions. The user can manipulate the system values that control auditing and control user and object auditing.

What are the main exposures?
It is a sound security practice to audit sensitive events on your system. How else would you know who deleted a file or who created a user profile? *AUDIT special authority must be reserved to user profiles that are responsible for system integrity, like the security officer.

How Special are your users?

I hope I have shown that you must not assign special authorities in a haphazard manner. The exposures are just too great. Determine a workable plan for assigning special authorities to your most trusted and responsible users, and remember, not all users need special treatment.

----------------------------------
About the author: Dan Riehl is president of The 400 School, the popular iSeries training company, and co-founder of The Powertech Group, one of the leading providers of iSeries security software.

USER FEEDBACK TO THIS TIP

  • I found your article -- "The danger of indiscriminately assigning special authorities" -- of particular interest, since I am consulting for a client currently undergoing changes predicated by Sarbanes-Oxley. I've had numerous discussions with the auditors regarding their IT Audit Report, specifically denoting the *JOBCTL special authority. As indicated in the "Main Exposure" paragraph, *JOBCTL has inherent control properties, including the ability to power down the system. What was not mentioned is a very fundamental control function, that is, having authority to the PWRDWNSYS command. Generally, the PWRDWNSYS command is restricted from *PUBLIC use and limited to QSECOFR and system operator profiles. Without authority, no profile can execute this command.
    --Alan D. Lowe, President Lowe's Consulting Inc., IBM Midrange Systems Consulting


 

This was first published in November 2002

Dig deeper on iSeries system and application security

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchEnterpriseLinux

SearchDataCenter

Close