Comments on: Change QSECOFR profile

By: TomLiotta

TomLiotta — Tue, 11 Dec 2012 11:30:38 +0000

The user class has nothing to do with any authorities (except for providing defaults when creating the profile). It doesn’t matter if a profile is given *USER, *SYSOPR, *PGMR or any user class. Ignore it.

A *SECADM special authority can be inherited from a group profile. Or authority might be adopted by a program from the program’s owner. Or the authority might be gained by running a function that swaps to an authorized profile; then anything the authorized profile can do becomes available. Or any number of other methods might be available depending on your OS version, software loaded on your system, your system QSECURITY level and other possibilities.

If you want to investigate deeper, you might review the Check User Special Authorities (QSYCUSRS) API. That can indicate if a special authority is naturally available to a given user. If it is not, the the special authority is being obtained by some programmed method.

Tom

By: Meetmeonline

Meetmeonline — Tue, 11 Dec 2012 10:27:11 +0000

Hi Tom,
There are few user profiles in our shop which has *USER class and has special authority *JOBCTL, but these user profiles have ability to enable & disable other user id’s. If *SECADM is mandatory to perform this,then why and how these profiles could do so? I want to know what all measures to be taken to avoid providing user’s the ability to perform such activities.
There is another user profile that has *SYSOPR class and special authority *JOBCTL and *SAVSYS. This profile can change other user profiles. I want to restrict both the user class *USER and *SYSOPR the ability to modify other user profiles.
Please let me know why these profile have the ability to do so and how can I stop them from having the access.
Thanks

By: TomLiotta

TomLiotta — Tue, 11 Dec 2012 01:51:49 +0000

Can a QSYSOPR profile change QSECOFR user profiles,

First, what do you mean by “change”? Many things about QSECOFR cannot be changed by any profile. Second, what authorities have been given to QSYSOPR? Without knowing what QSYSOPR has assigned, there’s no way to know what it can do. It shouldn’t be changed except to set a non-default password,

Can QSYSOPR change normal user profiles.

Which normal profiles? What changes are to be made? What authorities have been assigned?

If yes, then which parameter gives the ability to change any other user id?

Generally, to change *USRPRF user profiles, the *SECADM special authority needs to be assigned. And to change any specific profile, there must be at least *CHANGE authority to that profile. The special authority allows running commands to manage user profiles. But even if commands are allowed, the command actions can only work against authorized profiles.

What security measures should be taken to avoid providing user profiles the ability to enable or disable other user id’s?

First, don’t give authorities to IBM-supplied profiles except as directed in IBM documentation. There might be some changes needed for some IBM-supplied products such as a web server. When possible, create your own profiles and assign the authorities to those.

Second, don’t give any authority to any user profile that doesn’t need it.

QSYSOPR needs no additional authorities and should not be given additional authorities. If you want operators to have authority to do anything that QSYSOPR can’t do, then create a profile and grant authorities there.

Tom