You're not missing the boat Joe, you're exactly right.
The system verifies a user's authority to an object in the following
order:
1. Object's authority - fast path
2. User's *ALLOBJ special authority
3. User's specific authority to the object
4. User's authority on the authorization list securing the object
5. Groups' *ALLOBJ special authority
6. Groups' authority to the object
7. Groups' authority on the authorization list securing the object
8. Public authority specified for the object or for the authorization
list securing the object
9. Program owner's authority, if adopted authority is used
In the distant past one easy way to reduce authority lookups and
response times was to grant Public *ALL authority at the object level or
give users *ALLOBJ rather than spend the time and effort required to set
up the proper authority. Those (pre-network?) security models tended to
consider application or menu based security good enough. Now we have
users (and others!) coming in from all directions, ODBC, JDBC, FTP,
HTTP, etc. Many of these bypass "legacy" security measures.
The modern world of SOX and PCI compliance demands a much higher level
of diligence. Do you know anyone still running at SECLVL 10 or 20?
Regards,
Scott Ingvaldson
Senior IBM Support Specialist
Fiserv Midwest
-----Original Message-----
From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
Sent: Thursday, April 03, 2008 9:36 AM
To: Midrange Systems Technical Discussion
Subject: Re: Installing running applications as QSECOFR
John Earl wrote:
Additionally, there are certain functions that just can't be done
without QSECOFR authority ... user profile handle switching, for
example. You an do it if you know the user and password you are
switching to, but in order to do the handle switch WITHOUT requiring
the userid & password, you need QSECOFR authority.
User profile switching requires *USE to the object. Given the
difficulty of creating your own "FRED" profile and making sure it
always has *USE authority to every profile it might ever want to
switch to (including profiles not yet created), giving "FRED" *ALLOBJ
seems like a reasonable compromise. But it is likely also be
unnecessary to provide "FRED" with the other seven Special
Authorities.
I don't even buy the *ALLOBJ, John. It seems to me that any automation
process - and in the end, that is what an SCM system is: an object
distribution automation - ought to follow the exact same security
policies as the manual procedures it replaces. In the case of object
creation and distribution, the programmer does the initial object
creation. My guess is they don't ever need to sign on as QSECOFR or
indeed as anything but their own profile to do their job. So that part
of the process ought to run under their profile. And I don't think it's
too hard to identify the profile to the SCM; that would be part of your
standard procedure of setting up a programmer, wouldn't it? I mean,
really, how much work is it to grant authority to a user profile?
Object promotion is different, but once again in my opinion it ought to
exactly mirror the manual process. Now, if in your shop you have to
sign on as QSECOFR every time you put a program into production, then
probably you have an argument that you need to assign QSECOFR to that
task in your SCM. However, I think we would probably all agree that
requiring QSECOFR to install into production probably isn't the best
answer. Instead, there should probably be a "PROMOTE" user profile that
has enough authority to do these things, and that is the profile that
the promotion task should run under.
I don't know, maybe I'm missing the boat. It sure seems to me, though,
that given the ease with which we can swap profiles today that it ought
to be a piece of cake to use the right profile for a task, rather than
use carte blanche authority.
Joe
midrange.com
