Hi Morag,
The KC quote you mention is describing the fact that when a user creates a queue they are given access to everything on that queue making they privileged, or an administrator, of that queue.
Based on that description I worry that readers might think "that doesn't sound too dangerous" and grant +crt for users or apps that are already semi-privileged, so I feel a need to clarify here. This is not directed at you since I know you know this already, but meant as a reference for others who do not.
The danger this KC passage refers to is that of creating an alias over the command queue, or any other queue which serves a privileged process.
In the case of user-written or 3rd party applications, very few go to the trouble of checking the MQMD.UserID so the ability to put a message to that app's command or service queue allows full access to the application serving the queue without requiring any advanced function like +setid or +altusr. Just create an alias and in nearly all cases it's possible to drive whatever transactions the app allows. Update an account address? No problem. Forge purchase orders? Yup. Any privileged function that app supports is up for grabs.
Similarly, an alias over a normally-protected XMitQ opens up all destinations on the adjacent QMgr(s). If the shop has gone to the trouble of protecting XMit queues and using QRemotes or QAliases over clustered objects to control who can put where, an alias over the protected XMitQ nullifies the effects of all those security controls. The only requirement of the user is to know how to build their own XMQ header when placing messages on the alias.
Some non-IBM programs and most IBM components actually do perform an authorization check against the MQMD.UserID so to exploit these the user must be able to set that field. In this case the user with +crt who creates an alias inherits +setid and +altusr on the new alias queue and potentially can spoof any user ID when putting messages to, say, SYSTEM.ADMIN.COMMAND.QUEUE. Fortunately, IBM was good enough to require +setid to be granted on both the QMgr and on the queue so this isn't a straight shot to spoofing identity, but +crt removes one of only two constraints.
That dual constraint combined with the requirement to set the MQMD.UserID when putting messages onto the command queue is why the KC says +crt "indirectly" grants full admin access. The remaining constraint, +setid on the QMgr, is legitimately required for many semi-privileged applications that need to propagate identity - such as WAS or IIB. If such an application is granted both +setid and +crt, it's game over because that app is now effectively a full administrator. Of course many apps that don't require +setid on the QMgr are granted it anyway, a situation commonly discovered during audits and security assessments.
To sum up, there is no restricted form of the +crt authorization that limits it to certain queue names or certain types of queue. Anyone with +crt and who also has +setid on the QMgr is effectively a full administrator. Anyone who has +crt but doesn't also have +setid on the QMgr is still granted an extraordinary amount of elevated privilege on the local QMgr and any adjacent queue managers. (All QMgrs in a cluster are adjacent, by the way.)