Profiles, authorities and security levels

A user, here, is an object: a user profile, type *USRPRF, living in QSYS like everything else. It holds the password, the authorities, the job description its work takes settings from, the current library, the initial program.

There is no separate list for the database, one for the operating system and one for the application: whoever connects over SQL from a PC and whoever signs on to a 5250 session are the same profile, with the same authorities. One consequence not everyone accounts for: a profile designed for the green-screen application carries the same authorities into an ODBC connection, where the menus that constrained it are no longer there.

Special authorities

Eight authorities go beyond normal object checking:

*ALLOBJ is the obvious one. *SAVSYS and *SPLCTL matter nearly as much and get noticed less: whoever can save every object can carry it away, whoever sees all printed output sees the payroll too. And *JOBCTL opens confidential output when the output queue has OPRCTL(*YES).

Who has *ALLOBJ:

SELECT AUTHORIZATION_NAME, STATUS, SPECIAL_AUTHORITIES, TEXT_DESCRIPTION
  FROM QSYS2.USER_INFO
 WHERE SPECIAL_AUTHORITIES LIKE '%*ALLOBJ%'

SPECIAL_AUTHORITIES is a list of the profile's special authorities, each padded with blanks to eleven characters, and null when the profile has none: the LIKE searches inside that list.

Where the special authorities nobody remembers granting come from: CRTUSRPRF assigns them with SPCAUT(*USRCLS), that is by user class. Class *SECOFR gets all eight at every security level, *SYSOPR gets *SAVSYS and *JOBCTL. At levels 10 and 20 even a *USER is created with *ALLOBJ and *SAVSYS.

Object authorities

Beneath special authorities sits normal checking, which comes in two forms. Commands use four summary levels:

• *EXCLUDE: no access;
• *USE: read and run;
• *CHANGE: read and change the data;
• *ALL: everything, including deleting the object and changing its authorities.

Beneath the four levels are the real authorities, split between object (*OBJOPR, *OBJMGT, *OBJEXIST, *OBJALTER, *OBJREF) and data (*READ, *ADD, *UPD, *DLT, *EXECUTE). Day to day you work with the four; the ten matter when exactly one thing has to be granted: reading without being able to delete the object, say.

Every object also has a public authority, *PUBLIC, applying to anyone not otherwise provided for. For a new object it is set by the system value QCRTAUT, but only when the library has CRTAUT(*SYSVAL) and the object is created with AUT(*LIBCRTAUT); otherwise the library, or the command, decides. The value IBM recommends for QCRTAUT is *CHANGE, and the public can change new objects.

Groups and authorization lists

Authorities granted profile by profile soon become unmanageable. Two things make them governable:

Group profiles. A user can belong to a primary group (GRPPRF) and fifteen supplemental ones (SUPGRPPRF), sixteen in all; authorities are granted to the group and members use them. A group is an ordinary user profile: the system recognises it as a group when the first member is added. IBM advises against groups owning objects, because every member would then have the owner's authority to the object, deletion included.

Authorization lists (*AUTL). A list holds who may do what, and objects are told to follow the list. One operation grants a user authority to every object on the list; each user holds one private authority, the one to the list, which keeps profiles smaller and security data saves faster. Files get an extra benefit: by default an open file cannot have authority granted or revoked; if it is secured by a list, authorities can be changed even while it is open.

CRTAUTL AUTL(PAYDATA) TEXT('Payroll files')
ADDAUTLE AUTL(PAYDATA) USER(GRPPAY) AUT(*CHANGE)
GRTOBJAUT OBJ(PRODLIB/PAYROLL) OBJTYPE(*FILE) AUTL(PAYDATA)

Adopted authority

A program can run with the owner's authority in addition to the caller's: CRTxxxPGM ... USRPRF(*OWNER). *PGM, *SRVPGM and SQL packages can do it. It is the way to give the user *USE on the files, so that through SQL they can only read, and let the maintenance program do the updating.

What is adopted, according to IBM:

• the owner's private and ownership authorities, and those of its primary group; not public authority, and not the groups the owner belongs to;
• the owner's special authorities, *ALLOBJ included;
• authorities only: other profile attributes, such as limited capabilities, are not.

DSPPGMADP shows which programs adopt a profile's authority, and PRTADPOBJ produces a report. The use of adopted authority is recorded in the audit journal as AP entries when QAUDLVL includes *PGMADP; they are read with SYSTOOLS.AUDIT_JOURNAL_AP.

DSPPGMADP USRPRF(QSECOFR)

Security levels

The system value QSECURITY decides how seriously the system takes all this. Changing it needs *ALLOBJ and *SECADM, and the new value takes effect at the next restart.

DSPSYSVAL SYSVAL(QSECURITY)

Where to start on an inherited system

Four questions, each answered by one query or command:

1. How many profiles have *ALLOBJ, directly or through a group, and who are they really?
2. Are there enabled profiles that have not signed on for months? USER_INFO has the last sign-on in PREVIOUS_SIGNON.
3. What is QSECURITY set to?
4. Is auditing on (QAUDCTL other than *NONE) or is the system recording nothing of what happens?

Sources

• IBM: Special authority
• IBM: Create User Profile (CRTUSRPRF)
• IBM: USER_INFO view
• IBM: Authority for new objects (QCRTAUT)
• IBM: Group profiles
• IBM: Advantages of using an authorization list
• IBM: Objects that adopt the owner's authority
• IBM: AUDIT_JOURNAL_AP table function
• IBM: Change Security Auditing (CHGSECAUD)
• IBM: Security level (QSECURITY)
• IBM: Security level 20
• IBM: Security level 40
• IBM: Changing to security level 40