| Author |
Message
|
| fswarbrick |
 Posted: Mon Feb 12, 2024 9:47 am Post subject: SVRCONN and user rights under z/OS |
 |
|
Apprentice
Joined: 07 Jul 2014
Posts: 42
|
So we're having trouble locking down some users in our production z/OS MQ environment. The users in question only have READ access to most of the queues. Yet they are still able to write to the queues. And the access assigned is to the channel initiator user, rather than the actual user. The CHIN user has UPDATE to the queues, and this is what is allowing it.
We changed the RESLEVEL profile from READ to NONE, but the behavior seems unchanged. Neither the CHIN user nor the channel user are connected to the RESLEVEL group.
Are we missing something? |
|
| Back to top |
|
 |
| fswarbrick |
| Posted: Mon Feb 12, 2024 9:50 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014
Posts: 42
|
| Hmm, that's not actually true. A group that the channel user is in is connected to RESLEVEL. The channel initiator, however, is not. Which, if any, of these users (groups) should be connected to RESLEVEL? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Feb 12, 2024 2:19 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| zpat |
| Posted: Tue Feb 13, 2024 5:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Browse/inquire needs RACF READ.
Get/put needs RACF UPDATE.
MQOO_BROWSE
MQOO_INQUIRE
READ
MQOO_INPUT_*
MQOO_OUTPUT
UPDATE
MQOO_*_CONTEXT UPDATE
MQOO_SET
ALTER
https://www.mqtechconference.com/sessions_v2016/Securing_your_zOS_QMgr.pdf
RESLEVEL is a very strange design and I suspect many installations have security issues due to it (or lack of it).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 13, 2024 8:45 am Post subject: Re: SVRCONN and user rights under z/OS |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| fswarbrick wrote: |
| Are we missing something? |
You implied that your configuration works in TEST, but not in prod. What is different/new/changed?
What do your RACF-knowledgeable folks suggest?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fswarbrick |
| Posted: Tue Feb 13, 2024 9:07 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014
Posts: 42
|
We don't have this security on in test.
My RACF people are without a clue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 13, 2024 9:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You've provided near zero useful information to help you.
So, no TEST. Do you have a QA (pre-PROD) environment? Does whatever you are doing work in QA? Or, do you have no security in QA?
Again I ask: what is/are different about the user(s) and queue(s)? New users? New queues?
Why are you target-locked on RESLEVEL?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fswarbrick |
| Posted: Tue Feb 13, 2024 11:22 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2014
Posts: 42
|
No QA system. Just dev/test and prod.
This is likely not a new issue. Just one that no one noticed before.
I'm not "target-locked" on RESLEVEL. It's the only thing we've tried so far. We don't know what else to try; thus the query.
Sounds like we need to open a ticket with IBM. Thanks.
Frank |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 13, 2024 11:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Is the issue with only one SVRCONN channel? Or affecting all SVRCONN channels? What CHLAUTH rules for the channel?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| elkinsc |
| Posted: Tue Feb 13, 2024 12:08 pm Post subject: Please see this lab on MQ for z/OS Security |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 13, 2024 5:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do you have a CHLAUTH record that asserts an identity?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Feb 14, 2024 1:55 am Post subject: Re: SVRCONN and user rights under z/OS |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| fswarbrick wrote: |
So we're having trouble locking down some users in our production z/OS MQ environment. The users in question only have READ access to most of the queues. Yet they are still able to write to the queues. And the access assigned is to the channel initiator user, rather than the actual user. The CHIN user has UPDATE to the queues, and this is what is allowing it.
We changed the RESLEVEL profile from READ to NONE, but the behavior seems unchanged. Neither the CHIN user nor the channel user are connected to the RESLEVEL group.
Are we missing something? |
Step-by-step is always the best way to approach a security problem.
Are your client applications running for long enough to "catch" them with a running SVRCONN first of all?
If yes, use the DISPLAY CHSTATUS command to discover what the MCAUSER they are running under is.
Is this user ID the one that has READ access to the queues? If not, we should solve the problem of setting the correct MCAUSER at runtime for these applications.
If this user ID is the expected READ access user ID, then likely you have RESLEVEL set to check a single user ID (READ access for the CHIN ID) and the user ID that will get checked for queue access is the CHINIT user ID. I suspect your channel has PUTAUT(DEF). Would suggest if you want access checked against the MCAUSER, you set PUTAUT to ONLYMCA.
N.B. Read RESLEVEL profile and channels for a summary I wrote a while back.
Let me know the answer to the above question about the MCAUSER and we'll go from there.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 14, 2024 8:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| fswarbrick wrote: |
We don't have this security on in test.
My RACF people are without a clue. |
It appears that you have little or no security in prod, as well. Time to involve your internal and external auditors, and update your resume.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
