Tweet
I recently had a system that was in the development environment and once shifted to production environment, it was my job to remove the QSECOFR and other special authority away from the development team. I made my changes and ran Queries to verify that the system was locked down. A couple of days later a user that I had issued *PGMR and special authorities of JOBCTL and SPLCTL now had *SECOFR and all the special authorities. I ran journal to see how this could be. The journals showed that this user had change his own profile to get these authorities. When I looked into how this happened, I found that this user had assigned himself to the group profile of QSECOFR. Being a member of this group allows a user the same rights. I had no idea that this was possible. Why would the QSECOFR be a valid entry into this parm? Is there a way to eliminate this option? Sandy Howard Sabre Technology
-
-
Watch Out!!
On Thursday, December 10, 1998, 12:05 PM, Sandy Howard wrote: I recently had a system that was in the development environment and once shifted to production environment, it was my job to remove the QSECOFR and other special authority away from the development team. I made my changes and ran Queries to verify that the system was locked down. A couple of days later a user that I had issued *PGMR and special authorities of JOBCTL and SPLCTL now had *SECOFR and all the special authorities. I ran journal to see how this could be. The journals showed that this user had change his own profile to get these authorities. When I looked into how this happened, I found that this user had assigned himself to the group profile of QSECOFR. Being a member of this group allows a user the same rights. I had no idea that this was possible. Why would the QSECOFR be a valid entry into this parm? Is there a way to eliminate this option? It is insufficient to set the special authorities to correctly secure your system. In this case, the user profile QSECOFR profile waseligible to be used by that user -- I will call HACKER. In the simple case, either *PUBLIC or HACKER had sufficient authority to QSECOFR to perform work. You say that HACKER assigned his group... if so you did not say this was in the journal... so I expect this was already the case and was not removed. When a user is in a group they are granted authority to their group profile. All users with special authority must be reviewed for public and private authorities... and restricted from users as appropriate. Also, any program to which the user is authorized and adopts sufficient authority to access QSECOFR allows the user to effect the same. So too, all programs which adopt must be reviewed for possible exposure . There are other places like communication entries and network job entries that can be used to enable gaining access. I believe there is a security toolkit or some such by IBM to help address these types of issues; in your attempts to ensure your system is secure. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever. -
Watch Out!!
Your user must have had some form of authority to QSECOFR either directly through his/her profile or through program adoption. When trying to add QSECOFR as a group or supplemental group, and not authorized to QSECOFR, the user would have received CPF9802 if there was no underlying authority (somewhere).Comment
-
Watch Out!!
IBM only activated QINACTITV support for Telnet with OS/400 V4.2 so if you're running below that, Telnet sessions are not subject to these values. We have an article on the web called "What You Should Know about TCP/IP Display Emulation" by Becky Schmieding, who is IBM's PC5250 guru. In that article, Becky briefly talks about QINACTITV for Telnet. The URL is: target=_new href="http://www.midrangecomputing.com/ane/aneweb/99/01/9901-tcpip.htm"> target=_new href="http://www.midrangecomputing.com/ane/aneweb/99/01/9901-tcpip.htm">http:// www.midrangecomputing.com/ane/aneweb/99/01/9901-tcpip.htm You might also want to check your QINACTMSGQ value which specifies what action to take when a job has been inactive for a specified period. The value are *ENDJOB (end the job), *DSCJOB (disconnect the job) or to send message CPI1126 to a specified message queue. It could be that, instead of disconnecting or ending the job, a message is being sent to a message queue. Joe Hertvik Editor-AS/400 Network Expert (formerly Client Access/400 Expert) hertvik@midrangecomputing.com www.midrangecomputing.com/caeComment
Comment