Operations Navigator Opens Potential Security Exposure

Alert: When you install the latest version of Client Access V3R1M3, you may be opening the door for a new security exposure that did not exist in prior versions. The Operations Navigator in the latest version of Client Access allows an authorized user to delete production objects.

The typical installation of Client Access includes the GUI called Operations Navigator support. However, the latest version of Operations Navigator has added the capability to allow authorized users to point and click their way through object deletion, bringing with it the possibility of unintentional deletions even when users are not allowed to enter CL commands. It must be stressed that this exposure exists, however, only when users are already authorized to delete objects on the AS/400. The problem with many AS/400 installations is that users do have authority to production objects. This authority is granted through their group profile or *PUBLIC authority. If this authority additionally includes object existence (*OBJEXIST) authority, the potential for accidental deletion of objects increases.

The exposure for an authorized user to accidentally delete AS/400 objects using Operations Navigator is similar to the exposure I have discussed in this column before: the ability of Windows Explorer to map a network drive and then access QSYS.LIB objects. This exposure exists only when the user has the authority to delete, move, or rename the objects; however, the authorization list QPWFSERVER can be used to prevent users authorized to the objects from listing the contents of QSYS.LIB. This authorization list prevents Windows Explorer users from pointing and clicking their way to deletion of AS/400 objects. The Windows Explorer problem is easily prevented by not authorizing users to the authorization list QPWFSERVER.

In examining the problem of unintentional deletions by Operations Navigator, I have discovered the following:

• Operations Navigator ignores the Limit capability (LMTCPB) parameter in the user profile. This means that even when users cannot enter commands, they can still point and click their way to object deletion.

• If users have *OBJEXIST authority to objects, they can delete those objects.
• Operations Navigator is not controlled by the authorization list QPWFSERVER. Users must be authorized to this authorization list to catalog the contents of the QSYS.LIB in the AS/400 Integrated File System (IFS). However, Operations Navigator issues calls to system programs and does not use the IFS, so the authorization list is ineffective in preventing access.

I am still trying to understand the most efficient way to prevent accidental object deletion. So far, the only sure preventative measure I can see is to deny users the authorization necessary to perform actions you want to restrict.

Some AS/400 installations are not installing Operations Navigator when they install Client Access, thus preventing users from getting into trouble before it begins. If you take the option for the typical install of Client Access, the Operations Navigator support is installed on the PC. You must then use the selective install option from the accessories menu to remove Operations Navigator from the PC. Figures 1 through 4 show the screens required for the removal of Operations Navigator. Removing the Operations Navigator support will not prevent determined PC users from using it. They could reinstall the support on their PCs. The only way to prevent deletion is to not authorize users to objects.

I feel that IBM simply needs to provide better controls on the Operations Navigator. Too many existing AS/400 shops rely on their users not getting to production objects, so they give users too much access. There needs to be a way for system administrators to easily control selective use of Operations Navigator.

I shared my concerns about Operations Navigator with some of my former colleagues at IBM. The following is a response about these concerns from a “reliable source”:

• We agree about the unlimited access people get with Operations Navigator. Customers who have relied on menu “security” are now wide open, compared to the green-screen user interfaces.

• The good news is that, in the next version of Operations Navigator—due out very soon—we will provide the equivalent support to menu security. Administrators will be able to centrally manage who gets what functions when Operations Navigator accesses the AS/400. They’ll be able to set a system default and then override/change for specific users and groups. Lots of other new goodies are coming in the next release as well.

Objects Owned Prevent User Profile Deletion

Question: I have a user profile I cannot delete. When I try to delete it while signed on as the security officer, it comes back indicating that the profile owns objects. But the Work with Objects by Owner (WRKOBJOWN) command lists no objects. What gives?

Answer: A profile cannot be deleted when the user profile owns objects. The objects owned must either be deleted or transferred to another user profile. A user profile may actually own objects even when the WRKOBJOWN command states otherwise.

There are actually two types of objects on the OS/400. The external objects (such as *PGM, *FILE, and *CMD) are listed on the WRKOBJOWN. These are called external objects because they are shown to the users of the operating systems. But an external object

may be composed of multiple parts (objects). For example, a subsystem description *SBSD is actually several objects. There is no difference between external and internal objects at the machine interface (MI). The designers of OS/400 chose one of the pieces of a multipart object to be the external object and classified the other pieces as internal objects. Therefore, a user who creates an external object owns both the internal and external objects. When the external object is deleted, the associated internal objects should be deleted as well. However, in rare cases, such as object damage, the internal objects are left without a corresponding external object. When internal objects exist with no corresponding external object, you can issue the WRKOBJOWN command, and no objects will be listed, even though there may be internal objects that prevent deletion of the user profile.

The Owned Object Option (OWNOBJ-OPT) keyword, on the Delete User Profile (DLTUSRPRF) command has a *DLT option that will delete both the external and internal objects. Selecting this option should allow you to delete user profiles even if they are owners of orphaned internal objects.

Logging Remote Access from pcAnywhere

Question: I have a client running OS/400 Version 3.7 with people logging in remotely via pcAnywhere. Is it possible for system administrators to audit whoever logged in remotely? And if so, what logged information may be valuable to the administrators when they periodically review it?

Answer: pcAnywhere from Symantec is a PC utility that allows remote access from a connected PC. Using pcAnywhere, users connect to the host PC from another PC (usually in a different location) and operate the keyboard, mouse, and display as if they were sitting in front of the local PC.

If the host PC running pcAnywhere is attached to the AS/400, then the remote PC can access the AS/400. The AS/400 is unaware that the user is employing a utility program for remote access, so no special audit information is created. Standard AS/400 audit support can be used to select audit data for a specific user profile or job, but there will be no unique identification of audit data from pcAnywhere access.

However, while there is no AS/400-specific audit data, pcAnywhere does have an option to log remote connection sessions. The report created from these sessions identifies the remote callers and gives the date and time of connection. The activity log can provide detailed information (such as the files sent and received between the remote and host PCs) as long as the audit times in the pcAnywhere activity log are based on the PC time, not the AS/400 times.

Access by Disabled Profiles

Question: During a recent security audit by an outside company, the auditor stated that one of his clients had been hacked into by way of a disabled user profile. I wrote this comment off as typical of an auditor who doesn’t really understand AS/400 security. Was I wrong?

Answer: You were correct in that there is no exposure of a disabled user profile being used to access the AS/400. A disabled user profile cannot be used to sign on.

However, a disabled user profile can be used to run batch jobs, which may have been what the outside auditor was referring to in his comments. Many AS/400 installations disable user profiles to prevent sign-on when users are on extended leave. If you have a user profile that you do not want to delete (but which also should not sign on), I recommend setting the password to *NONE. This prevents sign-on, just like a status of *DISABLED. I prefer the *NONE setting because I then know that the security officer prevented the sign-on rather than repeated password failures disabling the user profile.

Using Primary Group Profiles for Performance

Question: I have a library named MGTDATA that contains several thousand files containing production data for our major application. The *PUBLIC authority for the objects is *ALL. However, our auditors want read-only access to everything in the library. I have set authority for all files to *PUBLIC - *ALL and have set a group profile, GRPAUDIT, with *USE authority to give the auditors the read-only access they want. Would an authority arrangement such as at shown in Figure 5 cause a slowdown in performance?

Answer: Before I answer your question, I want to warn you that giving the *PUBLIC an access of *ALL is not recommended. See the first topic for a new exposure with Client Access/400.

The security implementation is not optimized for performance. You have granted the user profile GRPAUDIT less authority than the *PUBLIC authority, thus setting off a performance flag in the header of every object. When the performance setting is off, the machine searches every user profile that opens the file to see if that user is the one with less access than*PUBLIC. As a result, you will have some slowdown in performance. Having said that, on the RISC models, IBM feels that the difference in performance for any of the different authorization mechanisms is so small as to be negligible. IBM stresses that if you have an authority scheme that is easy to understand and manage, then it is extremely unlikely that any substantial performance gains will be realized by changing it.

If you change your authority scheme to secure the objects with a Primary Group Profile (PGP) of GRPAUDIT, you can improve the performance. The PGP authority is stored in the object header. Every object on the system has an object header in which the machine stores the owners, PGP, and *PUBLIC authority. The PGP authority can be less than the *PUBLIC authority, but this will not turn off the performance flag in the object. When the performance flag is on for an object, the system doesn’t have to search individual user profiles if the *public authority is adequate. The command to change the PGP authority is Change Object PGP (CHGOBJPGP). The authority scheme shown in Figure 6 provides optimal performance. From an internal performance perspective, there are no “real” private authorities on this object. In other words, there are no private authorities less than *PUBLIC.

The authority for the owner, primary group, and *PUBLIC are shown in the same part of the list as private authorities, but they are not private authorities from the actual implementation of object authorities view. While the primary group authority is not a “real” private authority, it behaves the same way as a private authority would from a security point of view. We sometimes describe primary groups as a different kind of private authority.

In the example in Figure 6, you have no *PRIVATE authorities stored in the user profile; rather, all of the information is stored in the object header. Since the object has no *PRIVATE authorities, the performance will be optimal even though the user GRPAUDIT has less authority than *PUBLIC.

There are no “private” authorities. All of the authorities are stored in the object header. There is room in the object header to record the authority for *PUBLIC, *PGP, and object owner. (By the way, the size of the object header is unimportant; it is determined by IBM, and the user has no control over it.)

This use of Primary Group Profile illustrates how PGP can stand for Pretty Good Performance.

Removal of User Profiles

Question: In our company, user profiles are assigned based on job responsibility. When a person resigns, the system manager modifies the user profile description to “vacant,” and then changes the passwords of these user profiles by simply keying in some characters. I suggested that he change the password to *NONE, but the system manager is confident that the password of *NONE would allow anyone to sign on using those profiles and that no password is required.

Can a user profile with a password of *NONE sign on?

Answer: No. If the password of a user profile is *NONE, the user profile cannot sign on. The system manager has an incorrect assumption. IBM uses a password of *NONE for user profiles that are used to own objects but are not intended for sign-on, such as the user profile QSYS.

Assigning user profiles by functional area is not a good practice. When multiple individuals use the same user profile, individual user accountability is difficult to determine. The functional area user profiles can be used as group profiles. Individual users should be assigned a personal profile that reflects the appropriate functional area. The user profiles for former staff members should be deleted (removed from the system). Objects owned by these profiles should be transferred to active users or a general “owner profile” such as OWNPGMRS.

The Delete User Profile (DLTUSRPRF) command has an option that will change the owners of objects prior to deleting the user profile.

<>
<>
<>

Figure 1: Select Accessories from Client Access program group

 Figure 2: Selective setup from the Accessories program group

<>
<>
<>

<>
<>
<>

Figure 3: Delete options by removing check boxes

 Figure 4: Delete confirmation screen

<>
<>
<>

Display Object Authority

Object . . . .. . : DT050498_ 0 Owner .. . . . . : OWNMTG

Library . . . . : MTGE.BAKA Primary group . .: *NONE

Object type . . . . : *FILE

Object secured by authorization list . . . . . . . . . . . : *NONE

Object

User Group Authority

OWNMTG *ALL

@AUDIT *USE

*PUBLIC *ALL

Figure 5: Current authority scheme

Display Object Authority

Object . . . .. . : DT050498_ 0 Owner .. . . . . : OWNMTG

Library . . . . : MTGE.BAKA Primary group . .: GRPAUDIT

Object type . . . . : *FILE

Object secured by authorization list . . . . . . . . . . . : *NONE

Object

User Group Authority

OWNMTG *ALL

GRPAUDIT *USE

*PUBLIC *ALL

Figure 6: Performance improved by using Primary Group Profile

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility