What no one tells you about defining your RACF resources – and how to do it for MQ.

Introduction

The RACF documentation has a lot of excellent reference materials describing the syntax of the commands, but I could not find much useful information on how to set up RACF specifically for products like MQ, CICS, Liberty etc.

It is bit like saying programming has the following commands, load, store, branch; but fails to tell you that you can do wonderful things like draw Mandelbrot pictures using these instructions.

I set up MQ on my z/OS system as an enterprise user – though I have an enterprise with just one person in it – me!  With this view it shows what you need to configure.

I am not a RACF expert – but have learned as I go along.  I believe this blog post is accurate – but I may have missed some set up considerations.

In this blog post I’ll cover

• Security roles
• RACF concepts – class and profile
• Controlling who can create profiles and how to limit what they can create
• MQ profiles
• Planning for MQ
• How do you copy the security profiles for a new queue manager?

A typical enterprise – from a security perspective

In a typical enterprise there are different departments

• The security team responsible for the overall set up of security, ensuring that configurations are up to date (userids which are no longer needed are deleted).
• product teams are responsible for defining the security profiles within their products, protecting resources, and giving people access to facilities.
  • most developers do not have the authority to define profiles or give access.  Many developers do not have a z/OS logon.

What do you need to protect?

There are four types of resources you can define

• commands
• resources
• “logging on” or “connecting to”
• turning off security, or making powerful commands generally available

For example, for z/OS

• commands
  • being able to issue z/OS commands
  • being able to issue TSO commands
• resources
  • data sets
• logging on
  • which systems you can logon to
• turning off security
  • changing the RACF configuration

for MQ

• commands
  • being able to issue MQ commands to configure the queue manager
  • being able to issue commands to define MQ queues etc
• resources
  • queues, channels etc
• logging on
  • which queue managers you can use, connect from batch, but not from CICS
• defining the switches to disable parts of MQ security checking.

How do you protect a resource?

Resources are defined in classes. For example

• class OPERCMDS define z/OS console commands
• class MQCMDS for MQ commands
• class MQQUEUE for MQ queues
• class SERVER for managing access to servers such as Liberty and WAS

You need to go down a level, and protect resources within a class.  You may want to allow one group of people to define resources for production and another group allow to define resources for test.   You may have MQOPS allowed to define  profiles for PROD… and TEST…. and TESTOPS only allowed to define resources TEST…..

You need CLass AUTHorisation (CLAUTH) on a userid to be able to define a resource.  The CLAUTH does not exist for a group.

ALTUSER ADCDA CLAUTH(MQCMDS)

With this command userid ADCDA can now use commands like

RDEFINE MQCMDS MQPA.DISPLAY.** UACC(NONE)  OWNER(MQM)

This says

• Create an entry for class MQCMDS
• Queue manager MQPA, any DISPLAY command, so DISPLAY USAGE, and DISPLAY QLOCAL would be covered
• No universal access
• The resource is owner by MQM.   If this is a group, anyone with group special in group MQM can issue the PERMIT command on the resource

How specific a profile do I need?

For harmless commands, such as DISPLAY you can have a general profile MQPA.DISPLAY.* to cover all DISPLAY commands.

For commands that can change the system, you  should use specific profiles, for example

RDEFINE MQCMDS MQPA.DEFINE.PSID UACC(NONE)  OWNER(MQM)
RDEFINE MQCMDS MQPA.DEFINE.QLOCAL UACC(NONE)  OWNER(MQM)
PERMIT MQPA.DEFINE.PSID CLASS(MQCMDS) ACCESS(READ) ID(MQOP1)
PERMIT MQPA.DEFINE.QLOCAL CLASS(MQCMDS) ACCESS(READ) ID(MQAMD1)

If you use the DEFINE.** then administrators can give themselves access to the operator DEFINE commands.

Limiting what profiles a user can manage

If you have RACF GENERICOWNER enabled (this is a system wide option) you can create profiles and grant people access within that group.

Turn on GENERIC OWNER

SETROPTS GENERICOWNER

Create a top level, catch-all case

RDEFINE MQCMDS ** UACC(NONE) OWNER(SYS1)

Create a profile limiting people in group ADCD to define resources with names MQPC.**

RDEFINE MQCMDS MQPC.** UACC(NONE) OWNER(ADCD)

If userid ADCDA in group ADCD tries to create a profile

RDEFINE MQCMDS MQPC.AA3 UACC(NONE)

it works, but

RDEFINE MQCMDS MQPZ.AA UACC(NONE)

gives ICH10103I NOT AUTHORIZED TO DEFINE MQPZ.AA.

The owner of a profile can give authority to anyone, there are no limits or checks.

Creating profiles for MQ

Using the categories described above

• MQ commands
  • being able to issue MQ commands to configure the queue manager
  • being able to issue commands to define MQ queues etc
• MQ resources
  • queues, channels etc
• connecting to MQ
  • which queue managers you can use
• defining the switches to disable parts of MQ security checking.

MQ Commands

Commands can be issued from

• the operator console (SDSF)
• with the MQ ISPF panels,  messages are put to the SYSTEM.COMMAND.INPUT.QUEUE
• Applications putting messages to the SYSTEM.COMMAND.INPUT.QUEUE
• Applications using PCF to the SYSTEM.COMMAND.INPUT.QUEUE

If command checking is enabled then command are checked using the MQCMDS class.

Other commands, via the SYSTEM.COMMAND.INPUT.QUEUE, need to have permission to put to the queue, and the command is checked by the MQCMDS class.

MQResources

The queuing resources are  have the following classes – MX… are for MiXed case names. A completely UPPER case queue name can still be protected if you choose to use the MXQUEUE class. That is “upper case” names are a subset of the “mixed case” names, and MYQUEUE is different from MyQueue.

• MQQUEUE,MXQUEUE  queue resources
• MQPROC, MXPROC process (for example triggering)
• MQNLIST, MXNLIST name list
• MXTOPIC topics – Topics are always mixed case.

Connecting to MQ

• MQCONN  and you define resources like MQPA.BATCH CLASS(MQCONN)

Defining switches to disable parts of MQ security checking, and subset checks

• MQADMIN, MXADMIN, Profiles:

Used mainly for holding profiles for administration-type functions. For example:

• • Profiles for IBM MQ security switches
  • The RESLEVEL security profile
  • Profiles for alternate user security
  • The context security profile
  • Profiles for command resource security

For example the following turns off all RACF checking for the queue manager

REFINE MQADMIN MQPA.NO.SUBSYS.SECURITY

You can set up security so people are authorised to only a subset of objects.

You can set up

RDEFINE MQADMIN MQPA.QUEUE.TEST* OWNER(MQPAOPS)

to allow people access to a subset of queues – in this case queues beginning with TEST on queue manager MQPA.  A user would need to be authorised to use RDEFINE MQCMDS MQPA.DEFINE.QLOCAL  or (hlq.DEFINE.**)  and authorised to RDEFINE MQADMIN MQPA.QUEUE.TEST*.

A thought on the MQ profile design.

 It feels like the security was not well defined in this area.  You want to allow someone to restrict someone’s access to only use a subset of queues, but the person may have the authority to turn MQ security off by giving them authority to create MQADMIN MQPA.NO.SUBSYS.SECURITY!

You can solve this using GENERICOWNER (which is optional) and

RDEFINE MQADMIN MQPA.NO.** UACC(NONE) OWNER(THEBOSS)

Looking back, rather than depending on the GENERICOWNER facility,  I would have set up a class MQSWITCH to allow only the site RACF coordinator to define a switch and so turn off security.

Planning for security

You need to identify

• the classes of profiles ( MQCMDS, MQQUEUES, z/OS OPERCMDS)
• the subsystems being protected ( MQ, DB2)
• the areas of profiles,  TEST queues, Production tables for PAYROLL application
• the roles of people and what they are expected to do – map each role to a group
  • For each subsystem and class of profile what can each role do?
    • Production, Read Only operator commands, roles: all roles
    • Production, DEFINE PAGESET commands, roles: members of ZOPER group
    • Production, DEFINE QUEUE  commands, roles: members of PRODADMN group
    • Test, DEFINE PAGESET commands, roles: members of ZOPER and TESTOPER groups
• The hierarchy of groups.   If you have defined a profile with owner TESTOPER, people can create resources in this group
  • if they are in the TESTOPER group,
  • or a user who has group-SPECIAL authority over the group which owns the TESTOPER profile
• Define the profiles, the general MQPA.DISPLAY.**,  and the specific MQPA.DEFINE.PAGESET, MQPA.DEFINE.QLOCAL

Another thought of MQ security design.

At the beginning of MQ 25+ years ago, this was before Sysplex, there was only a single LPAR, and typically only one queue manager, DB2 etc on each LPAR.  These days people have many “identical” queue managers – which may be in a QSG or not.

When you create a new queue manager you have to replicate the security profiles, so copy all the profiles from MQPA…. to MQPB….

With hindsight it may have been better to

• define profiles with a generic name prefix, eg MQHLQ, so you would have MQHLQ.DEFINE.**
• have a queue manager option SECPFX=MQHLQ which points to these profiles
• have a class SERVER profile MQ.MQHLQ and grant the queue manager userid access to it.

How do you copy the security profiles for a new queue manager?

I could find no easy way of doing this.  When I worked for IBM I had some rexx code which used the IRRXUTIL  to extract information from the RACF database and rebuild the RDEFINE and PERMIT statements.

You could also use the RACF Unload Database program into a file, but most people are not likely to have access to the this.