ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Channel Security

Post new topic  Reply to topic Goto page 1, 2  Next
 Channel Security « View previous topic :: View next topic » 
Author Message
saurabh25281
PostPosted: Wed Jun 05, 2019 1:48 am    Post subject: Channel Security Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
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
View user's profile Send private message Send e-mail Yahoo Messenger
exerk
PostPosted: Wed Jun 05, 2019 2:22 am    Post subject: Re: Channel Security Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Jun 05, 2019 3:18 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Go to Google. Enter 'mcauser' as the search argument. The first hit was https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.con.doc/q082010_.htm
_________________
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
View user's profile Send private message
Vitor
PostPosted: Wed Jun 05, 2019 4:51 am    Post subject: Re: Channel Security Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed Jun 05, 2019 4:55 am    Post subject: Re: Channel Security Reply with quote

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
View user's profile Send private message
saurabh25281
PostPosted: Wed Jun 05, 2019 6:43 am    Post subject: Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
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
View user's profile Send private message Send e-mail Yahoo Messenger
exerk
PostPosted: Wed Jun 05, 2019 6:59 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Jun 05, 2019 6:59 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Jun 05, 2019 7:26 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
exerk
PostPosted: Wed Jun 05, 2019 7:29 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Jun 05, 2019 7:48 am    Post subject: Reply with quote

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
View user's profile Send private message
saurabh25281
PostPosted: Wed Jun 05, 2019 1:27 pm    Post subject: Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
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
View user's profile Send private message Send e-mail Yahoo Messenger
Vitor
PostPosted: Thu Jun 06, 2019 4:58 am    Post subject: Reply with quote

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
View user's profile Send private message
saurabh25281
PostPosted: Thu Jun 06, 2019 7:20 am    Post subject: Reply with quote

Centurion

Joined: 05 Nov 2006
Posts: 107
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
View user's profile Send private message Send e-mail Yahoo Messenger
exerk
PostPosted: Thu Jun 06, 2019 7:22 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » IBM MQ Security » Channel Security
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.