| Author |
Message
|
| saurabh25281 |
 Posted: Wed Jun 05, 2019 1:48 am Post subject: Channel Security |
 |
|
Centurion
Joined: 05 Nov 2006
Posts: 108
Location: Bangalore
|
Hi All,
I am trying to implement security on Sender, Cluster-Sender, Server channels and override the default behaviour that uses the privilaged access.
I added MCAUSER to the channel attribute, mapped ChlAuth rules to MCAUSER, for a userid that did not had authorizations on transmission queue, channels or DLQs.
I expected the channels to not start or atleast fail to get message from the transmission queue, but the messages went through.
Can someone please let me know, what is wrong with this approach or if it is not possible to override the default behavior for these channels.
Regards
Saurabh |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Jun 05, 2019 2:22 am Post subject: Re: Channel Security |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| saurabh25281 wrote: |
Hi All,
I am trying to implement security on Sender, Cluster-Sender, Server channels and override the default behaviour that uses the privilaged access.
I added MCAUSER to the channel attribute, mapped ChlAuth rules to MCAUSER, for a userid that did not had authorizations on transmission queue, channels or DLQs.
I expected the channels to not start or atleast fail to get message from the transmission queue, but the messages went through.
Can someone please let me know, what is wrong with this approach or if it is not possible to override the default behavior for these channels.
Regards
Saurabh |
The MCAUSER attribute is only valid for channel types of:
1. Receiver
2. Requester
3. Server connection
4. Cluster receiver
It's amazing what can be found in the Knowledge Centre 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 05, 2019 3:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 05, 2019 4:51 am Post subject: Re: Channel Security |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saurabh25281 wrote: |
| Can someone please let me know, what is wrong with this approach |
It's based on a misunderstanding of channel security.
| saurabh25281 wrote: |
| if it is not possible to override the default behavior for these channels. |
What "default behavior"? What "privileged access" are you trying to remove? And why at the sending side?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 05, 2019 4:55 am Post subject: Re: Channel Security |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| saurabh25281 wrote: |
| if it is not possible to override the default behavior for these channels. |
What "default behavior"? What "privileged access" are you trying to remove? And why at the sending side? |
I think the OP is perhaps a little vague on the fact the sending end is normally controlled by the authorities granted to the 'sending' application...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Wed Jun 05, 2019 6:43 am Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 108
Location: Bangalore
|
| Quote: |
The MCAUSER attribute is only valid for channel types of:
1. Receiver
2. Requester
3. Server connection
4. Cluster receiver |
Thanks everyone for pointing this out.
1. How difficult is it to disable the fields in MQ Explorer and in MQSC commands when someone tries to fill them up. Shouldn't the tools be in line with the documentation.
2. I get that the MCAUSER field is not applicable to specific channels, but how about the CHLAUTH rules. Is the mapping of channels to MCAUSER using CHLAUTH same as setting the MCAUSER field in channel? and in that case mapping users to these type of channels through CHLAUTH would not be valid.
3. The documentation says "The user ID associated with a sending channel requires access to the queue manager, the transmission queue, the dead-letter queue, and access to any other resources that are required by channel exits."
If the sender channels always uses the privileged user and cannot be set otherwise by using MCAUSER or by CHLAUTH rules, then is the statement in the document redundant as a privileged user anyways has all the access.
Regards
Saurabh |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 05, 2019 6:59 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| saurabh25281 wrote: |
| 1. How difficult is it to disable the fields in MQ Explorer and in MQSC commands when someone tries to fill them up. Shouldn't the tools be in line with the documentation. |
Ask the people at Hursley, they're the authority on such questions. Bear in mind though, that any values placed in non-applicable attributes will be ignored by the object.
| saurabh25281 wrote: |
| 2. I get that the MCAUSER field is not applicable to specific channels, but how about the CHLAUTH rules. Is the mapping of channels to MCAUSER using CHLAUTH same as setting the MCAUSER field in channel? and in that case mapping users to these type of channels through CHLAUTH would not be valid. |
Again, the Knowledge Centre will tell you which objects CHLAUTH rules apply to - read it is my advice.
| saurabh25281 wrote: |
3. The documentation says "The user ID associated with a sending channel requires access to the queue manager, the transmission queue, the dead-letter queue, and access to any other resources that are required by channel exits."
If the sender channels always uses the privileged user and cannot be set otherwise by using MCAUSER or by CHLAUTH rules, then is the statement in the document redundant as a privileged user anyways has all the access. |
If by 'privileged user' you mean an administrator-level user, then yes, that user will always have the access - you couldn't administer without that access.
And no, the statement is NOT redundant because, for example, a SDR channel services an XMITQ, and that needs an intermediate QREMOTE object.* An application should have ONLY the authority it needs, so (as a minimum) CONNECT to the queue manager and PUT to the QREMOTE. The queue manager will then do the rest. Of course, the receiving end should then have its objects locked down too, e.g. RCVR with an MCAUSER value (whether explicit, or implicit using CHLAUTH mapping).
Try Googling 'mq + secure messaging', the top hit is very relevant.
* In general, before I get flamed!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 05, 2019 6:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saurabh25281 wrote: |
| 1. How difficult is it to disable the fields in MQ Explorer and in MQSC commands when someone tries to fill them up. |
Ask IBM.
| saurabh25281 wrote: |
| Shouldn't the tools be in line with the documentation. |
Raise an RFE.
| saurabh25281 wrote: |
| 2. I get that the MCAUSER field is not applicable to specific channels, but how about the CHLAUTH rules. Is the mapping of channels to MCAUSER using CHLAUTH same as setting the MCAUSER field in channel? and in that case mapping users to these type of channels through CHLAUTH would not be valid. |
Mapping is done at the receiver side and follows the same rules as channel MCAUSER. Check any posts by @morag for more details and information on other matters such as precedence.
| saurabh25281 wrote: |
3. The documentation says "The user ID associated with a sending channel requires access to the queue manager, the transmission queue, the dead-letter queue, and access to any other resources that are required by channel exits."
If the sender channels always uses the privileged user and cannot be set otherwise by using MCAUSER or by CHLAUTH rules, then is the statement in the document redundant as a privileged user anyways has all the access.
|
That link talks about the authorities needed by the various channels. If the channels always used "the privileged user" (by which I assume you mean mqm) the entire link would be irrelevant as you'd never need to specifically set any permissions.
From the link you quote:
| Quote: |
| The user ID associated with a sending channel requires access to the queue manager, the transmission queue, the dead-letter queue, and access to any other resources that are required by channel exits. |
So you can use "the privileged user" (mqm) or any other non-human user of your choice
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Jun 05, 2019 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And I see nobody is talking about running the channel initiator with a non privileged userid... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 05, 2019 7:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| And I see nobody is talking about running the channel initiator with a non privileged userid... |
Didn't want to spoon-feed too much, hence the reference to the 'secure messaging' side of things  .
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 05, 2019 7:48 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Didn't want to spoon-feed too much, hence the reference to the 'secure messaging' side of things . |
 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Wed Jun 05, 2019 1:27 pm Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 108
Location: Bangalore
|
| Quote: |
| And I see nobody is talking about running the channel initiator with a non privileged userid... |
Thats the reason my Sender channel is running as privileged user. Thanks for the Hint.!!!
1. Is it a security risk to let the channel initiator run as a privileged user in Production environment? What is the potential risk?
2. If I have to run the Channel Initiator as a Qmgr service, with a non-privileged user, would the definition of the service be something like below?
| Code: |
| DEFINE SERVICE('CHANNEL.INITIATOR') CONTROL(QMGR) SERVTYPE(COMMAND) STARTCMD('sudo -u user /opt/mqm/bin/runmqchi') STARTARG('-m QM1 -q MYCHANNEL.INITQ') |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jun 06, 2019 4:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saurabh25281 wrote: |
| 1. Is it a security risk to let the channel initiator run as a privileged user in Production environment? |
So you don't trust the IBM code?
| saurabh25281 wrote: |
| What is the potential risk? |
What could the channel MCA do with that privileged access that you'd not want to happen?
IMHO you're worrying about the wrong things. I'd be more concerned with a bad actor spoofing their own copy of a sender MCA and inserting malicious or fraudulent messages into your MQ topology. I'd be more worried about applications running with privileged access putting messages on queues that don't belong to them or setting context that they shouldn't be doing. These are examples of a fairly long list of things I worry about.
| saurabh25281 wrote: |
2. If I have to run the Channel Initiator as a Qmgr service, with a non-privileged user, would the definition of the service be something like below?
| Code: |
| DEFINE SERVICE('CHANNEL.INITIATOR') CONTROL(QMGR) SERVTYPE(COMMAND) STARTCMD('sudo -u user /opt/mqm/bin/runmqchi') STARTARG('-m QM1 -q MYCHANNEL.INITQ') |
|
I don't know; I've never bothered to run the software as anything other than the privileged user.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| saurabh25281 |
| Posted: Thu Jun 06, 2019 7:20 am Post subject: |
|
|
Centurion
Joined: 05 Nov 2006
Posts: 108
Location: Bangalore
|
| Quote: |
| So you don't trust the IBM code? |
I trust the IBM code, but also understand that the default behavior is to reduce the complexity of the tool. Hence, wanted to understand from the experts, if the default behavior can make the system vulnerable. There must be a reason why IBM documents talks about what authorizations would be required on a sender channels for non-privileged users .
| Quote: |
| I'd be more concerned with a bad actor spoofing their own copy of a sender MCA and inserting malicious or fraudulent messages into your MQ topology. I'd be more worried about applications running with privileged access putting messages on queues that don't belong to them or setting context that they shouldn't be doing. |
We have already secured incoming connections i.e. Receiver, cluster-receiver & svrconns using ChlAuth (SSLPEERMAP) rules.
1. Still would try to understand the risks associated with running the Channel Initiator as privileged user.
2. Still would like to understand if the Channel Initiator service that I mentioned is a correct way of defining it.
| Code: |
| DEFINE SERVICE('CHANNEL.INITIATOR') CONTROL(QMGR) SERVTYPE(COMMAND) STARTCMD('sudo -u user /opt/mqm/bin/runmqchi') STARTARG('-m QM1 -q MYCHANNEL.INITQ') |
|
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jun 06, 2019 7:22 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Again - Try Googling 'mq + secure messaging', the top hit is very relevant.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
