New IT Jungle article about QSECOFR Dos and Don’ts

Posted on by Joe Hertvik

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

About Joe Hertvik

Joe is the owner of Hertvik Business Services, a service company providing written white papers, case studies, and other marketing content to computer industry companies. He is also a contributing editor for IT Jungle and has written the Admin Alert column for the past ten years. Follow Joe Hertvik on Twitter @JoeHertvik. Email Joe for a free quote on white papers, case studies, brochures, or other marketing materials.
This entry was posted in IBM i Tech Info. Bookmark the permalink.

4 Responses to New IT Jungle article about QSECOFR Dos and Don’ts

  1. Luis Rodriguez says:
    February 8, 2012 at 7:14 am

    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.

  2. Joe Hertvik says:
    February 8, 2012 at 8:59 am

    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.

  3. Michael Q. says:
    February 8, 2012 at 1:24 pm

    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

    • Joe Hertvik says:
      February 8, 2012 at 1:43 pm

      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.

Comments are closed.