Q: We are concerned that end-users can use the system-request menu to start a second session or sign off without completing a transaction. How can we prevent users from using the system-request menu?
A: A user can use the system-request key to suspend the current job and display the System Request Menu. The System Request Menu allows the user to send and display messages, transfer to a second job, or end the current job.
The public authority to the System Request Menu is *USE. An easy way to prevent end-users from accessing this menu is by restricting authority to the panel group QGMNSYSR in library QSYS.
The following commands prevent most users from seeing the System Request Menu. The first command revokes the public authority, the second one grants *USE authority to the users who are allowed to use the function.
RVKOBJAUT OBJ(QSYS/QGMNSYSR) + OBJTYPE(*PNLGRP) + USER(*PUBLIC) AUT(*ALL) GRTOBJAUT OBJ(QSYS/QGMNSYSR) + OBJTYPE(*PNLGRP) + USER(good_user) AUT(*USE)
If you want to allow users access to the system-request menu but restrict specific options, you can revoke access to the associated CL commands. 1 shows the system request options and their associated CL commands.
If you want to allow users access to the system-request menu but restrict specific options, you can revoke access to the associated CL commands. Figure 1 shows the system request options and their associated CL commands.
For example, to prevent users from transferring to an alternative interactive job, revoke public authority to the Transfer to Secondary Job (TFRSECJOB) command and grant authority only to specific users:
RVKOBJAUT OBJ(TFRSECJOB) + OBJTYPE(*CMD) + USER(*PUBLIC) AUT(*ALL) GRTOBJAUT OBJ(TFRSECJOB) + OBJTYPE(*CMD) + USER(good_user) AUT(*USE)
If a user selects an option he is not authorized to, the system displays a message. You may want to prevent users from general use of the commands on the System Request menu but still want them to be able to run one of these commands at a specific time (such as SIGNOFF). You can accomplish this by giving the users a menu option that calls a CL program which runs the command after adopting the authority of an authorized user.
Q: I am using the TCP/IP function on my system. How can the TCP/IP file transfer commands GET and PUT be secured?
A: You must use object-level security to control which files a user can access. Other file transfer facilities can be controlled by a user-written validation program specified in the network attributes. PC Support and Distributed Data Management (DDM) use PCSACC and DDMACC respectively. TCP/IP has no similar network attribute or system value that lets a validation program control the functions which are allowed. I contacted the IBM developers in Rochester and they could not give me any module names that could be secured. AS/400 security has many options, but sometimes I cannot find a solution to a problem. This question is a good example. If you have a solution, please contact me.
Security Patrol: Security Questions and Answers
Figure 1 System Request Commands
System Request Associated CL Description Option Command 1 TFRSECJOB Transfer Secondary Job 2 ENDRQS End Request 3 DSPJOB Display Job 4 DSPMSG Display Message 5 SNDMSG Send Message 6 DSPMSG Display Message 7 DSPWSUSR Display Work Station User 80 DSCJOB Disconnect Job 90 SIGNOFF Sign-Off
LATEST COMMENTS
MC Press Online