IT Jungle just published a new article I wrote about security issues I’ve encountered involving the QSECOFR security officer user profile, including the never-ending QSECOFR password; how changing the QSECOFR password took out a controller; and other tales of brain-challenged administrators and users.
You can read the article here.
After reading, let me know whether you’ve ever hit any of these issues (or others) and what you’ve done about it. You can email me here or post a note on the column on this page.
***************************************************
Follow Joe Hertvik on Twitter @JoeHertvik.
Tech company White papers, case studies, brochures, email campaigns, Hertvik Business Services writes them all. Email Joe Hertvik for a free quote.
Related Posts
IT Jungle: Six Things to Do Before Switching Production Processing to Your CBU
Power 7 Machines Will Not Vanish After PureSystems Availability
We’re Making Stew: Guidelines for Serial Blogging
IT Jungle: Cleaning Up Excessive Job Logs on Your IBM i Box
Keeping the Lights On through UPS Maintenance
Big IBM Announcement on Apri 11th–Integrated Expertise: Unveiling a New Era of Computing
Joe,
Found about your blog in ITJungle: Nice!! (Subscribed already!)
Let me add another one to your lists of QSECOFR gaffes (to use a mild word). Several years ago, when I began working at a new shop, I was given the job managing user’s profiles. Did a PRTUSRPRF and found that everybody had *SECADM!! (In fact, they had every entry enabled for SPCAUT). It seems that the previous QSECOFR (my new boss!!), when creating a new profile, just copied his own profile (I have to admit he took the effort of changing the TEXT parameter)… Almost had a heart attack on the spot.
That may be more common than you think. I never had the *SECADM experience you had, but I once consulted at a shop where everyone had *ALLOBJ authority. The explanation was that that they retrieved a lot of data via ODBC and no one wanted to take the time or trouble to authorize them only to the files they needed. So by default, everyone had access to everything.
Got that one cleaned up.
The problem is that IBM i is the most secure operating system in the world…if you take the trouble to secure it. I don’t care how much capability the system has, if a company is going to do stupid things like this, you’ve turned it into a vulnerable system.
And the list goes on.
Hi Joe,
Very good article. But can you elaborate on the situation where software had to be installed by signing on as QSECOFR?
We’ve had companies insist that but when we pushed and set up another profile (temporary in the type of situation you describe) with *ALLOBJ and *SECADM or whatever the real need was, the installation has always worked. The security algorithm in the IBM i checks for *ALLOBJ special authority. If it’s there, no further checking is done. Only a company writing poor quality software or with lazy programmers would check that you were actually signed on as QSECOFR.
We do have one ISV that I regularly correspond with where their installation routine checks that the profile performing the tasks has *ALLOBJ and *SECADM authorities. The reasoning they give for requiring it in the manuals clearly states that a program running with adopted authority is sufficient. It would be, but they are too stubborn and so hard-code the check for the authorities on the profile running the installation. BTW–this profile is NOT QSECOFR.
Thanks,
Michael
No specific instance where I know the software had to be installed by QSECOFR. Like you, I’ve run into vendors whose instructions say the software must be run by QSECOFR or a company specifies that they need QSECOFR access to install. As you said, maybe this is just a bad habit in the software industry to insure that a program is installed under a *ALLOBJ and *SECADM profile.
I’m with you on this. I’m all for minimizing QSECOFR use wherever possible. The way to totally check for QSECOFR necessity is for admins to install software under a non-QSECOFR profile on their development partition, and then put the new product through its paces. If you’re running any kind of robust test script on the new software, you should know pretty quickly whether there’s an installation problem.
Anyone else out there know of an instance where software won’t install unless run under QSECOFR?
***************************************************
Follow Joe Hertvik on Twitter @JoeHertvik.
For White papers, case studies, brochures, email campaigns, email Joe Hertvik at Hertvik Business Services for a free quote.