Where Have All the Job Logs Gone?

Question: We are running V2R3. Users with QPGMR authority cannot view job logs from Work with Active Jobs (WRKACTJOB).

Any suggestions?

Answer: There are three possible reasons your users with QPGMR authority cannot view job logs:

• Viewing the spool files of another user requires *JOBCTL special authority. The QPGMR profile should have *JOBCTL authority unless someone has removed that authority. Does your QPGMR user profile have *JOBCTL authority?

• Can your QPGMR user profile view its own job log? If not, the problem may be that the Display Spooled File (DSPSPLF) command is restricted and you need to grant access.

• A user such as QPGMR without security officer authority cannot view the job log of a security officer (who has *ALLOBJ and *SECADM authority). This restriction was implemented on S/38 when the job log included the password on the Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF) commands. On the AS/400, the password is omitted in the job log, but the restriction on the display of the spool files is retained.

You stated that you were on V2R3. If that is correct, you need to upgrade to V3R2 and apply some PTFs to be Y2K-compliant. IBM has dropped support for V2R3, so upgrading is extremely important.

Token-Ring Security

Question: At our shop, we are on an AS/400 150e box, V4R2, which we feel is secure. However, most of the connections to our AS/400 are made via a 16-MB Token-Ring network. Is all of our AS/400 security for naught if we haven’t placed any extra security on the Token-Ring network? How safe are our user IDs and passwords, which are being sent across this network from Client Access? Is the solution to this problem to purchase a third- party product to ensure the safety of this data, or would you recommend a different approach?

Answer: Security over the Token-Ring is important, but many AS/400 installations with an in-house Token-Ring do not secure the Token-Ring network. If your Token-Ring is installed on-site, your main form of protection is to lock up the wiring cabinets, making it more difficult to scan the network.

You were correct to be concerned about the user IDs and passwords. There are two times when you enter a user ID and password using Client Access. When you first connect to the AS/400, a user ID and password are transmitted, although not in clear text. The second time the user ID and password are transmitted occurs when you sign on to the AS/400. This time, the password is transmitted in clear text and is therefore subject to being discovered if someone is tracing the communication line.

If your Token-Ring is on-site, the cost of installing a third-party product to ensure protection of the data is probably not justified.

Adopted Authority for File Transfer

Question: I am using IBM’s Client Access V3R2 PC5250 and have display and password caching turned off. When I open my display session, it requests a user ID and password to connect to the AS/400. (I log on using profile XXX.) My AS/400 sign-on display now pops up, asking me to provide a user profile and password. (I sign on using my own user profile.) Then, I start an interactive application that adopts the rights of the user profile YYY, granting me access to the data. While in the application on my PC5250 display session, I minimize the session staying in that application.

Because my display session has adopted the access rights to that data, can I now get at the data by some other means, such as file transfer? If so, how can I stop this from happening?

Answer: Applications such as file transfer do not get adopted authority. The adopted access applies only to the interactive AS/400 session. The other sessions will run with the authority of the user profile that was used to connect to the AS/400 (in your case, user profile XXX). Client Access has drop-down menus on the top of the PC5250 session for file transfer, but selecting these will run the file transfer in a separate process, so you will not get adopted authority.

ODBC Access

Question: I have four ODBC-related security questions:
• How do I best protect my system from ODBC programmers?
• Are exit points the only way to restrict ODBC users?
• Do you have samples of exit points that work?
• Would it make more sense for me to have the programmers use FTP instead of ODBC?

Answer: The good thing about the AS/400 is that all access is controlled by AS/400 security, including ODBC access. The user profile used to connect to the AS/400 is the user profile that will determine the access for files using ODBC. You can restrict ODBC access using standard AS/400 security, and exit points are not the only way to limit user access.

A problem frequently faced by AS/400 installations is that users are given access to production files for interactive applications, so users are therefore authorized to run ODBC or file transfers to access files. Some installations solve this problem by writing exit programs to supplement object-level security. Exit points are often used to limit users from accessing the data via ODBC or file transfer. Exit programs are described in the IBM manual AS/400 Client Access Host Servers V4R2 (SC41-5740-01). IBM-provided servers allow you to supplement security using exit programs. Some third-party servers do not support exit programs, and your only control is through object-level security on files.

Writing exit programs can be a complicated task when you attempt to restrict specific files in the exit program. I recommend that you create a library to hold the files allowed for file transfer. The exit program can then reject any file transfer and ODBC requests other than access to the specific library. This approach allows you to determine what files can be transferred simply by determining what library is used for the file.

There is no security reason to use FTP over ODBC. Both FTP and ODBC are able to use exit programs to supplement object-level security, and for complete file transfer operations, FTP is much faster than ODBC.

The Tricky Nature of Adopted Authority

Question: My client has over 500 programs that adopt QSECOFR. What is the real risk behind programs adopting the authority QSECOFR? If programs are run by users with less authority, can they adopt the authority of the object owner (*ALLOBJ special authority), or are they still restricted?

Many programs need QSECOFR authority to run, so what should we recommend to our clients to ensure that excessive access is not granted to other users? Is it OK to allow programs to adopt this authority as long as the programs are fully supported and not “homegrown”?

Answer: Having a large number of programs that adopt QSECOFR is not uncommon in many AS/400 installations. I would prefer that applications not adopt such a powerful profile, but unfortunately, many third-party applications are written with programs that do adopt QSECOFR. When programs adopt any *ALLOBJ user, such as QSECOFR, the programs have access to all objects in the AS/400. Often, these application designers are taking a shortcut in their security design and are relying solely on application security, although it would be better if they allowed AS/400 object authority to control what the user could access.

A user with less authority running a program that adopts a user profile such as QSECOFR has the combined access of both the adopted user profile (*ALLOBJ special authority in the case of adopting QSECOFR) and the signed-on user. Design of programs that adopt is critical; the application must not allow the user to enter commands while running with adopted authority.

Preferably, applications should adopt a user profile that is the owner of production data files and is authorized to the production data but is not a user profile with *ALLOBJ authority. This way, installations can use AS/400 security to restrict access to sensitive data, such as payroll or human resource files. If the applications adopt a user profile with *ALLOBJ authority, such a restriction is not possible.

Using application packages rather than homegrown applications reduces the potential of a “back door” in the software through which sensitive data can be accessed.

X + Y = ?

Question: In an earlier edition of “Security Patrol,” you described adopted authority very well; however, there is one case about which I am uncertain.

Here’s the scenario. Program A uses adopted authority of *OWNER and has an owner of X. This program calls program B, which uses adopted authority of *OWNER and has an owner of Y. It also calls program C, which does not adopt authority. Which owners’ authority will program C adopt?

Answer: When multiple programs that adopt authority are called, the process runs the combined authority of all adopted user profiles and the signed-on user profile. In the case you describe, the process adopts both profile X and profile Y, while programs A and B are on the invocation stack.