| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Can chlauth prevent altusr as mqm |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Tue Sep 23, 2014 11:32 pm Post subject: |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I didn't investigate z/OS features too much, and I didn't conclude that from your earlier post since I'm not a native English speaker, to me sudo and sudoers was a trigger to start thinking about that feature and propose enhancements. Sorry, now when I read it again, that is about exactly what is needed, that you can set particular alternate users (hopefully multiple) permission for a certain user, if that was possible only for particular queues too, that would be even better. All in all, if you implemented it already there, go ahead and do the same for the other platforms. |
|
| Back to top |
|
 |
| jcv |
| Posted: Wed Sep 24, 2014 8:45 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| The purpose of this questioning was to find valid case for using PUTAUT(CTX), which the Security Redbook authors rightfully claim does not exist, but at the moment when I started thinking of it, I haven't read that their conclusion yet. They however don't claim more generaly that there is no valid case for using alternate user id. Both chapters are titled with "Avoid using...", but the conclusion is not exactly the same, because they seem to see some legitimate cases of using altusr. To what category of entities would you grant such permission? MQ administrator (in a sense of staff member charged with mq admin duty) does not need it, application user must not have it, there is only that third category of entities that would run such trusted applications (like MCA's, which would use it through PUTAUT(CTX)), that could potentially have it, but for which there is already a conclusion that there is no valid case of using it. Is it a small inaccuracy from their side, or do they take into account z/OS features there, or is there something else here? |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Sep 24, 2014 11:14 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| OK, it seems that inaccuracy was mine. MCA is a trusted application, but due to untrusted input, you cannot trust it to which queue it will try to write, and succeed if there is putaut(ctx). On the other hand, that web application from that scenario is trusted in a sense that you know to which queue it will try to write, but you cannot know as which user it will try to write. Is that it? |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Sep 24, 2014 11:45 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| But on the other hand, isn't "trusted application" actually an oxymoron? For example, MCA really is not that, it is, well, ... MCA. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 24, 2014 11:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
| jcv wrote: |
| OK, it seems that inaccuracy was mine. MCA is a trusted application, |
Yes and no. It is trusted code because it is written by IBM. (IBM trusted code means that its design met strict adherence to coding standards; and, as a result, won't violate storage or threads, will attempt error recovery, will produce meaningful messages, that kind of thing.) But, your implementation/configuration can make the MCA behave in an untrusted way if, for example, you let it run with unbridled mqm authority - which means it can open any queue.
| jcv wrote: |
| ... but due to untrusted input, you cannot trust it to which queue it will try to write, and succeed if there is putaut(ctx). |
Again, the MCA will behave in an untrusted way if you allow any user/group permission to open the QRemote definition.
| jcv wrote: |
| On the other hand, that web application from that scenario is trusted in a sense that you know to which queue it will try to write, but you cannot know as which user it will try to write. Is that it? |
Stop looking at this at the micro level. A front-door lock cannot be considered "secure" if there is an "unsecure" back-door lock; or, if you leave the windows open.
Look at this at the transaction-level. If any user can launch an app, then the app will do what it's written to do. If any app can access any queue, there is no security.
Security is like an onion - many layers. Any single point-of-failure (SPOF) == no security.
_________________
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 |
|
|
| jcv |
| Posted: Thu Sep 25, 2014 9:23 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I wasn't talking about trusting an application in order to allow it to fastpath connect to qmgr. I can trust channels and allow that, but what I also trust about them is that sender chl won't do anything else with queues but get from xmitq which I'm telling it to, and receiver won't do anything else but put to destination queue XQH header tells it to, or from wherever it reads that information, it doesn't matter now. But I'm not supposed to trust that some application will only put to a certain queue just because someone is telling me it's written to do so, or because I see so at the moment. An administrator is supposed to trust it only if he can constrain it through permissions. That's probably why people who are well informed think altusr was a bad idea, and I can only second their opinion. But some people seem to disagree, that's why I asked them what they actually think. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 25, 2014 10:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
| jcv wrote: |
| I wasn't talking about trusting an application in order to allow it to fastpath connect to qmgr. |
I did not intend my comments to be related to fastpath execution (of user applications), itself a bad idea.
| jcv wrote: |
| I can trust channels and allow that, but what I also trust about them is that sender chl won't do anything else with queues but get from xmitq which I'm telling it to, and receiver won't do anything else but put to destination queue XQH header tells it to, or from wherever it reads that information, it doesn't matter now. |
Sure.
| jcv wrote: |
| But I'm not supposed to trust that some application will only put to a certain queue just because someone is telling me it's written to do so, or because I see so at the moment. An administrator is supposed to trust it only if he can constrain it through permissions. That's probably why people who are well informed think altusr was a bad idea, and I can only second their opinion. But some people seem to disagree, that's why I asked them what they actually think. |
The job descriptions of a sysadmin and an internal auditor are usually different as they apply to assuring that applications meet business requirements, and comply with GAAP (generally accepted accounting principles).
Yes, the developers should be supervised, their code tested and validated, end-users and auditors need to certify, change-control methods need to be employed. Can/should you assist with all of this? Yes.
_________________
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 |
|
|
| sunny_30 |
| Posted: Fri Feb 06, 2015 5:59 am Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Sorry to open up this old thread. Appreciate the help !
I want to make sure I have good understanding. here is my Question
If an application genuinely requires altusr access, and is assigned such access at QM level to the mcauser of that svrconn, are we saying there is no facility within MQ that can prevent/check if the application switches over to mq-admin (say mqm on unix) user ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 06, 2015 1:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
| sunny_30 wrote: |
| ... are we saying there is no facility within MQ that can prevent/check if the application switches over to mq-admin (say mqm on unix) user ? |
su is an o/s function. The Unix commands sudo and su allow access to other commands as a different user.
MQ doesn't know or recognize (or care) how a user logs in/on, whether from an o/s prompt (telnet, rlogin, ...) or an su. Once you su, and provide mqm group credentials (your example), you are a systemadmin. Membership in the mqm group grants to sysadmins all privilege to all MQ commands and resources.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Fri Feb 06, 2015 3:04 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| sunny_30 wrote: |
Sorry to open up this old thread. Appreciate the help !
I want to make sure I have good understanding. here is my Question
If an application genuinely requires altusr access, and is assigned such access at QM level to the mcauser of that svrconn, are we saying there is no facility within MQ that can prevent/check if the application switches over to mq-admin (say mqm on unix) user ? |
Unless you are using a queue manager on z/OS, that is correct.
If you open an RFE to allow the same on non z/OS queue managers, I would vote for it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Feb 10, 2015 11:34 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3265
Location: London, ON Canada
|
| PeterPotkay wrote: |
| Unless you are using a queue manager on z/OS, that is correct. |
Are you sure that MQ on z/OS will check the specified altusr? It will check the UserID against the queue being opened and if the privilege of altusr is allowed but I don't remeber the actual alternate UserID value being checked.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Feb 11, 2015 1:45 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1967
Location: Bay of Plenty, New Zealand
|
Roger,
The profile checked for Alterate User authority on z/OS is of the form:-
| Code: |
| hlq.ALTERNATE.USER.userid |
So if user MORAG wants to use MQOO_ALTERNATE_USER_AUTHORITY and supply and AlternateUserId ROGER, then user MORAG requires UPDATE access to profile hlq.ALTERNATE.USER.ROGER.
See more in Profiles for alternate user security
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Feb 11, 2015 4:09 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3265
Location: London, ON Canada
|
Interesting. I did not know it did the 2nd check.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
