December 5, 2012 - Vol 2, Issue 20
Cilasoft Security Solutions - Intelligently Engineered Security Solutions
Cilasoft Security Solutions - Intelligently Engineered Security Solutions

Powertech - Secure Inside and Out

Security Training for IBM i from Skyview Partners

The "Hidden" Security Configuration Options

By Dan Riehl

There are vast concealed treasures in some of the deep, dark recesses of our wonderful IBM i—hidden configuration options that give you tighter, more customized control. For many of us, these treasures have been elusive, yet they've been so close at hand. Just a click away, a CL command away. IBM hasn't tried to keep these treasures hidden, but, as far as I know, IBM hasn't gone out of its way to educate us about them either. These "hidden" configuration options let you customize access to several security-, system-, and network-related functions through a simple CL command interface or through Navigator for i (Navigator, for short).

The CL commands Work with Function Usage (WRKFCNUSG), Change Function Usage (CHGFCNUSG), and Display Function Usage (DSPFCNUSG), are the command interfaces to these "hidden" configuration options. Navigator provides access to these configuration options through a little-known application I discuss shortly.

What Is "Function Usage"?

Sensitive Control Language commands and system operations are typically restricted to a select group of users through a combination of object authorities (i.e., are you authorized to use the command?) and special authorities (i.e., do you have the special authorities (e.g., *SECADM, *JOBCTL) required to run this command or function?).

Function Usage is an additional hidden layer placed on certain sensitive operations. For example, to create a user profile, a user needs to be authorized to use the command Create User Profile (CRTUSRPRF), and then the CRTUSRPRF command checks whether the user running the command has Security Administrator (*SECADM) special authority. If so, the profile can be created. In this case, no additional hidden Function Usage configuration options are involved.

When a user wants to examine the active joblog of an *ALLOBJ user (e.g., QSECOFR), however, the user must be authorized to the DSPJOBLOG command, must have Job Control (*JOBCTL) special authority, and must have *ALLOBJ authority. Those are the system's default rules. But by changing the hidden configuration options of Function Usage, you can override the rules to let anyone with *JOBCTL special authority view the active joblog of the *ALLOBJ user.

Because these configuration options are hidden in Function Usage, most of us concede to giving the operations staff *ALLOBJ authority. There seems to be no other way of allowing them to view the active joblog of an *ALLOBJ user when the job has failed. They must be able to troubleshoot the problem by viewing the active joblog. But we can change the rules by changing the Function Usage.

Viewing the JOBLOG of an *ALLOBJ User - Work with Function Usage

IBM maintains a registry of functions that provide hidden configuration options via Function Usage. One of the functions, as we've discussed, is the configuration of which users can view the active joblog of an *ALLOBJ user. The registered name of that function is QIBM_ACCESS_ALLOBJ_JOBLOG.

To access the settings for these registered functions, IBM has provided the CL commands Work with Function Usage (WRKFCNUSG), Change Function Usage (CHGFCNUSG), and Display Function Usage (DSPFCNUSG). The following Figure 1 shows the resultant screen when the command WRKFCNUSG FCNID(*ALL) is used.

From this screen, you can display or change the settings on the various functions listed.

Figure 2 (click here) provides a complete list of all the available functions in IBM i OS 6.1.

If you select option 2 (Change usage) for the function named QIBM_ACCESS_ALLOBJ_JOBLOG, you're presented with the Change Function Usage (CHGFCNUSG) command prompt, as shown here in Figure 3.

In this example, we specify that members of the group profile GRP_JOBLOG can access the job log of an *ALLOBJ user, and that the default for other users is to deny access. We also specify that if a user has *ALLOBJ authority, that authority can be used to provide access to the joblog of other *ALLOBJ users. To learn more about the CHGFCNUSG command, see the reference at the IBM i Information Center.

Which Functions Have Special Hidden Function Usage Configuration Options?

The previously referenced Figure 2 shows the list, by category, of those functions for which you can provide customized access by manipulating the Function Usage values. As the figure shows, you can configure controls for numerous functions, including:

  • Who can access the active joblog of an *ALLOBJ user?
  • Who can run a communications (service) trace?
  • Who can watch any job?
  • Who can send files by using the IBM i OS FTP client?
  • Who can download a file by using the FTP server?
  • Who can run the RMTCMD.exe from his or her PC to this system?

Application Administration: GUI Version of WRKCFNUSG

IBM i Navigator for Windows provides access to the Application Administration tool. This tool is, in effect, the GUI interface to the WRKFCNUSG facility—a much friendlier interface, I might add. To access this tool, in Navigator, right-click your system name or IP address and select Application Administration, as shown here.

Figure 5(above) shows the Application Administration main window with the "Host Applications" tab selected. The list of functions is the same as those in the text based WRKFCNUSG command display above, but in the GUI format. You then click the name of the function you want to customize. The Customize button becomes active. Click the Customize button.

Figure 6 (below) shows how you can select the users and customization options for the Access job log of *ALLOBJ job function. Again, here we see that Group_ops is "allowed" to display the job log of *ALLOBJ users. When your customizations are complete, click OK.

Figure 7 (Below) shows the Service Trace function with the group Group_Sec set as "allowed" to run service traces, such as Start Communications Trace (STRCMNTRC). The communication trace facility needs to be tightly controlled because it can easily be used to harvest User IDs and Passwords in a non-SSL Telnet environment or non-SSL FTP environment. When SSL isn't used for these applications, User IDs and Passwords are sent in clear text and can be easily captured by running a communications trace on your ethernet line.

Figure 8 (Below) shows customization for Allowing the downloading of files to your PC via FTP. In this figure, you can see that we're letting only the groups Group_ops and Group_sec use the FTP server to download files (send files, from the server's perspective, as shown in the figure). To accomplish that configuration, we clear the Default access check box and the Users with all object system privilege check box. Clearing the checkbox for users with all object privilege specifies that not even QSECOFR or other *ALLOBJ user can use FTP to download files, unless they're in one of the allowed groups. Again, there's no audit trail of FTP access unless you have a network exit point program that provides for this logging.

Important Security Notice: Implementing controls in the Client applications tab, like ODBC, RMTCMD, GUI Downloads or using the Excel add-in for file transfer shouldn't be considered as a comprehensive security solution for these functions. These rules are placed in the client Windows Registry, which can be easily edited to remove or alter the rule.

However, the Host Applications tab rules(e.g. FTP Server) are implemented at the host level, and can provide robust security for the Host Applications like FTP (e.g. JOE can use the FTP GET function).

A comprehensive commercial network exit point program solution typically provides more customizable protection, even to control access at the user/object level. However, in the absence of a robust network exit point program solution, these Function Usage network restrictions should be implemented. Function Usage does not provide any audit trail of Network access events, whereas most commercial network exit point solutions do provide that capability.

Document and Communicate the "Hidden" Configuration Option Settings

When you customize access by Function Usage Settings, remember that the configuration options are hidden from most users. Who, besides you, knows what rules have been set up in Application Administration or through the WRKFCNUSG command?

When users are restricted from functions, and they don't know why they've been rejected, there has to be a method in place for your system administrators and the help desk to know why users are being rejected. Is it one of your hidden configuration options? Make sure that you document and communicate these configurations as appropriate and that the staff knows you're using Application Administration and Function Usage configurations.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group, LLC.

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn

Training from The 400 School