Article View: bit.listserv.asm370
Article #311Re: Authorizing Address Space
From: Paul V DAngelo
Date: Mon, 05 Sep 2005 18:22
Date: Mon, 05 Sep 2005 18:22
100 lines
4820 bytes
4820 bytes
Some products do not allow Authorized Libraries or Functions. One that comes to mind is MQSeries on Z/os, MQ Does not allow Security Exits in a Channel Initizator to be Authorized. Having stated that, It was not disclosed to me what products or services they are talking about. I just happne to know About MQ. If the product does not allow An apf Authoried service to be used the installation needs to build there own environment, hence an Authorizing SVC. Customer may not be able to authorized there routines because the product exits be be in a Non Authorized State and the exit programs may loaded from a non authorized library. -pd- ======================================================================== On Mon, 5 Sep 2005 18:06:12 +0300 Binyamin Dissen <bdissen@dissensoftware.com> writes: > On Mon, 5 Sep 2005 10:46:21 -0700 Paul V DAngelo <essteam@juno.com> > wrote: > > :>I have a client who would like me to develop a presentation on an > :>Authorizing Address Space. > :>I suggested simply writting an SVC that switches Authorizations > instead > :>of and address space. > :>That Suggestion was fround upon. > :>They are building this facility to alow Vendor Products and As > well As > :>IBM products > :>to issues Authorized Services where I the Vendor does not > usually/easily > :>permit it. > > Such as? > > :>The customer would like to develop a cross memory environment; > :>issue a Program Call Instruction form a vendor product address > space to > :>thecustomers > :>Authorizing Server Address Space and allow the caller to be in > :>Supervisor State key xx or APF Authorized. > > Why can't they simply APF authorize those programs that require it? > > :>I believe an SVC could be developed to accomplished this, but I > suspect > :>theres more to this that > :>what they are telling me. > > Could be done as a PC as well. > > But...... > > :>My first question is when the Cross Memory Program is executed, > it would > :>Sets the APF Authorization bit > :>and return. WHo IS in the APF state, The entire Calling Address > Space or > :>only the invoking TCB ? > > APF applies to a job step task. > > But........ > > :>Can anyone on the list speak to the pros vs cons of developing an > :>Authorizing SVC > :>against an Authorizing Address Space. > > It is usually very wrong to set APF from an uncontrolled environment > (not > loaded from APF authorized libraries). > > The service should be encapsulated. > > :>I also suspect that Some Security Checking would be done in this > Address > :>Space, > :>since that was the first concept they had me explore. > > How will they verify an uncontrolled environment? > > -- > Binyamin Dissen <bdissen@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. >
Technical Details
Message-ID:
<20050905.112220.-344155.1.essteam@juno.com>Path:
arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!news.glorb.com!usenet.INS.cwru.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-03!sn-xit-08!sn-xit-14!supernews.com!149.173.6.116.MISMATCH!foggy!vm.sas.com!juno.com!essteamShow Full Headers
Complete Article Headers
X-Google-Thread: fcdcb,605a50893b34558
X-Google-Attributes: gidfcdcb,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: arc1-ca.pugleaf.net!g2news1.google.com!news4.google.com!news.glorb.com!usenet.INS.cwru.edu!newsfeed.berkeley.edu!ucberkeley!sn-xit-03!sn-xit-08!sn-xit-14!supernews.com!149.173.6.116.MISMATCH!foggy!vm.sas.com!juno.com!essteam
From: Paul V DAngelo <essteam@juno.com>
Newsgroups: bit.listserv.asm370
Subject: Re: Authorizing Address Space
Date: Mon, 5 Sep 2005 11:22:18 -0700
Organization: SAS Inc.
Lines: 100
Sender: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU>
Message-ID: <20050905.112220.-344155.1.essteam@juno.com>
NNTP-Posting-Host: mozart.unx.sas.com
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Trace: foggy.unx.sas.com 1125934610 27180 10.19.150.41 (5 Sep 2005 15:36:50 GMT)
X-Complaints-To: usenet@unx.sas.com
NNTP-Posting-Date: Mon, 5 Sep 2005 15:36:50 +0000 (UTC)
Comments: Gated by NETNEWS@VM.SAS.COM
Return-Path: <owner-assembler-list@LISTSERV.UGA.EDU>
X-Mailer: Juno 4.0.11
X-Juno-Line-Breaks: 0,2-3,5-7,9-11,13,15-20,22-99
X-Juno-Att: 0
X-Juno-RefParts: 0
X-ContentStamp: 37:18:915078507
X-MAIL-INFO: 25f36ab79317c7936b8b176b0b5f9bdbde3a0b7ef73a9aafdb4a9aabb793aa73da
b3dac373
X-UNTD-OriginStamp: pGaTaRWyPYyDUXJZwv+qaWLOrTCjg1kO8evjyE9EucNO8z5nr+tx7Q==
X-UNTD-Peer-Info: 127.0.0.1|localhost|m12.nyc.untd.com|essteam@juno.com
Approved-By: Paul V DAngelo <essteam@JUNO.COM>
Return-Path: owner-assembler-list@LISTSERV.UGA.EDU
X-OriginalArrivalTime: 05 Sep 2005 15:36:48.0281 (UTC)
FILETIME=[A0E9C890:01C5B22F]
Originator: daemon@mozart.unx.sas.com