Should Programmers Have *ALLOBJ Special Authority?

Question: We do not have a large data processing staff. Our AS/400 production applications use a third-party software package, and the third-party vendor has a user profile with *ALLOBJ special authority access to our AS/400. The software vendor indicated that this level of access is required to service the software application. Because our system contains payroll and customer lists, I am concerned that third-party programmers have this level of access. Is there an alternative to allowing programmers *ALLOBJ special authority?

Answer: Third-party and in-house programmers request this level of access so they can service production applications, a process that sometimes requires programmers to change production data files. Programmers request *ALLOBJ special authority because it is expedient.

I do not recommend blindly giving programming staff *ALLOBJ authority. If, for example, your AS/400 contains sensitive information such as the company payroll, enabling programming staff to view production files allows for the possible exposure of a programmer discovering the salary of a peer or supervisor. Consequently, major problems in office politics and coworker relations can arise, not to mention more urgent security risks that deal with actual dollars and cents.

You need to trust your programming staff, but try to avoid granting programmers *ALLOBJ special authority, because it increases the potential for unintended modification or deletion of production data. Programmers claim they cannot do their job unless they have *ALLOBJ special authority, but they can perform the majority of their program design and testing without it. In addition, *ALLOBJ special authority is not easy to remove once a programmer has been granted it.

There are times, however, when programmers need *ALLOBJ access. The key is to allow programmers this special access while preventing its potential abuse. Some installations give programmers two user profiles: one for normal work and a second with *ALLOBJ authority. As a deterrent to prevent access to sensitive files, the user profile with *ALLOBJ authority may audit all commands entered.

The problem with a second user profile is that programmers do not like to sign on a second time and frequently use the *ALLOBJ authority profile instead of the standard profile. I have implemented a command I call LOGCMD, which audits commands and gives the user adopted *ALLOBJ authority. I’ll give you the details of LOGCMD in next month’s “Security Patrol.”

Query/400 Question

Question: Is there a way to restrict particular users from querying a specific file or library? I have tried explicitly excluding users from the object and library, but Query/400 keeps letting them query the file. They do not belong to any group profile or authorization list that grants them access to the object. I am puzzled by this and need to know what to do.

Answer: I am also puzzled by your situation. In my experience, users must be granted access to the library and file to run Query/400. Your users must have *USE access to the particular library and file. If they are not authorized, they will get a message stating that fact.

I suspect your users may have accessed the files and libraries by some method you may have overlooked. Check for the following:

• Verify that your user and group profiles do not have *ALLOBJ authority using the Display User Profile (DSPUSRPRF) command.

• Verify that your users are not running a program that adopts the owner’s authority and that adopted access allows users to access the library.

• Verify that *PUBLIC authority to the library and file does not give users access. If you cannot find any source of authority, create a sample file and user to verify that a user profile must have *USE authority to the file and library. Create a test profile and file in a library not authorized to access the test profile. Then, run Query/400 and confirm that you are getting an authority violation message.

Adopted Authority Follow-up

Question: Your April 1999 “Security Patrol” described adopted authority very well, but I am uncertain about a particular type of case. If program A uses adopted authority *OWNER and has owner X; calls program B, which uses adopted authority *OWNER and has owner Y; and calls program C, which does not adopt authority; which owner’s authority will program C adopt?

Answer: When multiple programs in the invocation stack adopt authority, the adopted authority is the combined authority of all program owners’ access. In your example, when program C is running, both programs A and B are in the invocation stack and adopt their owners’ access. When running program C, access includes the following:
• The authority of the user running the job
• The adopted authority of user X from program A
• The adopted authority of user Y from program B

Level 30 to Level 40 Security

Question: We are hosting our own Web site from our production AS/400 and are currently at security level 30. I want to move to level 40 before we go live on the Internet but am afraid to change for fear of authority problems. What is the best way to plan for level 40 security before actually making the move?

Answer: I concur with your decision to move to security level 40. Moving to security level 40 is easy. Before changing system value QSECURITY to 40, you should determine if all your applications run at that level. OS/400 provides audit options that can determine if

your applications run at that level. You should stay at security level 30 and turn on the audit options using the following steps:

1. Create a journal receiver:

CRTJRNRCV JRNRCV(AUDLIB/AUDRCV0001) +

THRESHOLD(5000) AUT(*EXCLUDE) +

TEXT(‘Auditing Journal Receiver’)

2. Create the QSYS/QAUDJRN journal:

CRTJRN JRN(QSYS/QAUDJRN) +
RNRCV(AUDLIB/AUDRCV0001) +
AUT(*EXCLUDE) TEXT(‘Auditing Journal’)

3. Set auditing system values QAUDLVL and QAUDCTL to activate the audit options:

CHGSYSVAL SYSVAL(QAUDLVL) VALUE(‘*PGMFAIL’)
CHGSYSVAL SYSVAL(QAUDCTL) VALUE(‘*AUDLVL’)

After you turn on the audit options, the system records any potential problems associated with security level 40. You can view the audit data using the following Display Journal (DSPJRN) command:

DSPJRN JRN(QSYS/QAUDJRN)

Option 2 from the security tools menu (GO SECBATCH) generates a report of the entries in the audit journal. Any level 40 violations are reported by journal code AF (authority failure). This option from the security tools menu extracts the information from the audit journal and creates a report.

I recommend auditing through a month-end close so all production applications are tested. With any luck, the audit journal contains no data, indicating that you can move safely to security level 40. If any problems are recorded in the audit journal, you should not move to security level 40. Determine which program is causing the problems and contact your software providers to determine if they support security level 40.

Control Telnet Access

Question: Our AS/400 runs on V4R2 and uses Windows 95 Client Access over a Novell network using TCP/IP. Our AS/400 has a valid IP address and can be seen from the Internet. At this time, however, we do not have a firewall set up, and it will probably be a while before we can install one. I wanted to stop the outside FTP and Telnet access. Client Access does not use the FTP server to transfer files, so I could turn off the FTP server, and because Client Access uses the Telnet server, I could turn off that server to block Telnet use from outside. However, how can I block Telnet from outside and still use Client Access from our local network?

Answer: You can prevent FTP by not starting the server as you suggested. Other servers such as SMTP (Simple Mail Transport Protocol) should also not be started unless they are used.

I contacted IBM and confirmed that you must have the Telnet server active for Client Access users to use the PC5250 interface. You can write an exit program for the exit point QIBM_QTG_DEVINIT to prevent Telnet access. Based on my research, there is no way to distinguish between a Client Access PC5250 start request and a Telnet session. Your only alternative is to check the origination IP address in the exit program and allow

access only from your internal network. IBM has provided example Telnet exit programs written in C on its Web site at www.as400.ibm.com/ tstudio/tech_ref/tcp/Indexfr.htm.

Directly attaching a production AS/400 to the Internet without a firewall is dangerous: You are exposed to denial-of-service attacks. A hacker could send a large volume of requests (usually very short transactions with invalid requests), and your AS/400 would be kept busy rejecting the invalid requests so no productive work could be performed. I caution against putting a production AS/400 directly on the Internet.

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