The Hidden Crevices of OS/400
Author: Carol Woodbury
Although they may seem like subtle issues, the areas of OS/400 discussed in this article could be giving unscrupulous users easy access to data or the ability to perform functions they shouldn't be allowed to perform. Read on to determine if you need to apply some sound OS/400 Security Principles to these areas on your system.
Multiple copies of a command or an API that does the same function
I know many installations that secure certain commands such as Create Library (CRTLIB), End Job (ENDJOB), Change Library List (CHGLIBL) and others. Depending on your security policy and goals when securing commands, this practice may be one you want to follow. To make sure you have really and truly locked down these commands, you must find every instance of them.
For example, the CRTLIB command exists in four libraries on my system: QSYS, QSYSV4R5M1, QSYSV5R1M0 and QSYS38. Although none of the commands created specifically for OS/400 exist in QSYS38, many commands that you use routinely do. Administrators tend to forget about this library, but programmers (especially those who used to program on S/38) have not. The QSYSV* libraries are installed to enable compiling CL programs to previous releases. To make sure you've found all instances of the commands you're trying to secure, run the following command:
WRKOBJ *ALL/cmd_name *CMD
If you're working with the Integrated File System (IFS) an OS/400 version of the command and a traditional UNIX command both may perform the same function. A good example is the OS/400 Create Directory (CRTDIR) command and UNIX Make Directory (MKDIR) commands.
In addition to watching for multiple instances of a command, you also need to look for APIs that perform the same function as a command and secure those as well. For example, remove() deletes a file and rename() renames a file. Users should have sufficient authority to do the requested operation, just as they do when the run the corresponding command. But if you have not had the opportunity to implement a good object security scheme, many users will have the authority to perform these operations.
Objects that are not being used
If you think you can just ignore products that are no longer used, libraries that contain old programs, and data and directories that have been used to test various Java tools, think again. Just because it looks like no one is using them, doesn't mean that they do not present a security risk. All products, libraries and directories have security implications, whether or not they are used. If the library is *PUBLIC *CHANGE (or greater), users could store programs or files. In most cases, directories are created with *PUBLIC having the equivalent of *ALL authority. Unless this authority is reduced, these directories can be used to park inappropriate material, such as pornography, illegal copies of movies, customer data, and so forth. Much as we'd like to think otherwise, this type of thing does happen in the iSeries-world. Many products have functions that, when you look at them more closely, you don't want the general user community or development group to run. If the product is on the system, you have to make this determination and secure it appropriately. If the product is not being used, why waste your time on this exercise?
Profiles that are *PUBLIC *USE or greater
Profiles that are *PUBLIC *USE or greater let users assume that profile. For example, users can submit a job under another profile if they have *USE authority to the profile. By default, when profiles are created, they are created with *PUBLIC authority set to *EXCLUDE. So you might not think to check the *PUBLIC authority of user profiles. But profiles whose *PUBLIC authority has been set to *USE or profiles where users have been granted *USE authority can pose a significant security risk, especially if the profile has *ALLOBJ special authority. Profiles with *ALLOBJ or other special authorities let any user have and exploit these special authorities for themselves.
Job descriptions that name user profiles can also pose a significant security exposure. At security level 30, users only have to have authority to the job description (and not any user profile named in the job description) to use it. At security level 40 and above, you have more protection. Users have to be authorized to both the job description and a profile named in it. But if a profile is publicly authorized, users can still exploit a job description, even at level 40 or 50.
To find users that have a private authority to user profiles and to see profiles' *PUBLIC authority setting, run the following:
Unsecured copies of Production (private and confidential) data
The contents of application databases and the need to secure those databases that contain confidential and private data are starting to get some focus. But many times, the focus stops with the production version of the database. The problem is that this database usually shows up in more environments and on more systems than just production. Production data also often shows up on a development system or partition where security is often ignored. Programmers have no more reason to have access to private data than most of the end users of the application. But often, this private and confidential data is wide open to developer and tester access. Production databases also often reside on backup tapes. Think about who has access to these tapes when you are questioning how secure the confidential and private data your company collects really is.
TCP/IP Servers that are started and don't need to be
The rule that I use with my clients is that if the function that is provided by a TCP/IP server is not being used on the system, then that TCP/IP server should not be started. You should periodically examine the auto-start values of your TCP/IP servers. You can view some servers' auto-start value by using Configure TCP/IP (CFGTCP) but that is not a complete list. To see the complete list of servers, you need to use iSeries Navigator. Click the system name >Network >Servers >TCP/IP. This interface also offers the quickest and easiest way to see what servers are currently running. You should monitor the auto-start values because this value determines which servers are started when Start TCP/IP (STRTCP) runs. But you also should periodically check to see what servers are actually running. I've seen a case where the auto-start value for the FTP server was *NO but the OS/400 Start up program explicitly started it.
IBM profiles can be used in a couple of subtle ways that may cause security exposures. One way is to modify the profile. The modification I usually see is to add special authorities. My favorite is where QUSER has been given *ALLOBJ. Given that this is the default profile under which DDM runs, this situation is pretty scary. Adding special authorities to IBM profiles can unintentionally give users more authority than was intended because IBM profiles are used to run OS/400 functions. Unfortunately, they also are often used to own third-party applications. Adding *ALLOBJ special authority to QPGMR, for example, may be giving *ALLOBJ to the users running a third-party application that is owned by QPGMR. This configuration is especially dangerous if a command line is presented and can be used by some users
Another subtle way that IBM profiles can pose a security risk is by assigning them as a group profile. QPGMR seems to be the most popular IBM profile that ends up as a group profile. The reason this can be dangerous is because of the OS/400 commands QPGMR has been authorized to, the OS/400 objects QPGMR owns, and the third-party applications that are often owned by QPGMR. Any object QPGMR owns, every member of the group also owns. So every member can take any action they want to against these objects. They can delete the library, modify the file, re-create a program, and so on. In addition, during OS/400 installation, QPGMR is given private authority to many commands, including some you probably don't want members to be running such as Start TCP/IP (STRTCP), End Job Abnormal (ENDJOBABN), End TCP/IP (ENDTCP) and Reclaim Storage (RCLSTG).
Before making a user a member of an IBM profile, I suggest you run the following commands to determine exactly what objects the user will be authorized to and the objects they will own:
DSPUSRPRF USRPRF(IBM_PROFILE) *OBJOWN and
DSPUSRPRF USRPRF(IBM_PROFILE) *OBJAUT
Do the "crevices" of your system need a good housecleaning? Now is the time to examine your system's configuration and see if some housekeeping is in order.
Carol Woodbury is co-founder of SkyView Partners, www.skyviewpartners.com, a firm specializing in security consulting and assessments as well as assessment software, SkyView Risk Assessor for OS/400. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol can be reached at firstname.lastname@example.org