October 13, 2011 - Vol 1, Issue 1

Hidden Configuration Options for IBM i Security and Systems Management


Customize access to sensitive functions and system operations

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.

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). 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 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 Figure 3 shows. In this example, we specify that members of the group 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 Http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/cl/chgfcnusg.htm 

Which Functions Have Special Hidden Function Usage Configuration Options?

Figure 2 shows a list, by category, of those functions for which you can provide customized access by manipulating the Function Usage values. As Figure 2 shows, you can configure controls for several 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

Navigator 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 Figure 4 shows. 


Figure 5 shows the Application Administration main window with the Host Applications tab selected. The list of functions is the same as those in Figure 1's WRKFCNUSG display, but in the GUI form. You then click the name of the function you want to customize. The Customize button becomes active. Click the Customize button. Figure 6 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 can display the job log of *ALLOBJ users. When your customizations are complete, click OK. 


Figure 7 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 TCP/IP line. 


Figure 8 shows customization for downloading 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.

NOTE: 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 FTP GET).

A comprehensive commercial network exit point program solution typically provides more customizable protection and usually also provides an audit trail of network access events. However, in the absence of an exit point program solution, these Function Usage network restrictions should be implemented.

Document and Communicate the "Hidden" Configuration Options

When you customize access to functions by using these tools, 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.

Dan Riehl is the president and security specialist for the IT Security and Compliance Group, LLC. Dan performs IBM i security assessments and provides customized security services for his customers. He also provides training in all aspects of IBM i security and other technical areas through his training company, The 400 School, Inc.

The orignal article, from which this article is adapted, first appeared in System iNEWS magazine.