When creating authorized code I use the following guidelines:
- It is not good enough that the authorized code "functions" as
designed. Authorized code has a higher standard that it must adhere to.
Your code must not allow malicious or uninformed users to make it do
things outside of its scope.
- Pay attention to how you obtain your parameters.
- Parameters should be accessed in the requesters PSW Key.
- Make a copy of the parameters so that they cannot be changed
after you have validated them and before you use them (time of check 2
time of use vulnerability).
- Make sure sensitive data is kept in fetch protected storage.
- Make sure your design does not allow the requester to control where
the authorized code branches to:
- By branching to a user specified address in an authorized state
- By branching on a function code whose value is not verified
to be in a specific range
- Be careful issuing authorized services in your code AND allowing
user parameters to be specified in the authorized services parameter list.
- Return data to requester in their PSW Key.
- Don't return control to the requester with a higher level of authority
- Don't dynamically elevate their security credentials
- Don't allow the requester the ability to MODESET
- Don't return control in a different PSW Key or State
Ray Overby
Key Resources, Inc
Ensuring System Integrity for z/Series
(312) 574-0007
On 12/1/2013 7:47 PM, Jim Thomas wrote:
Shmuel,
Thank you for your responses, this and previous.
I concur w/what you've said and w/what others have said. Before I go on, as
Peter pointed out, I admit that I've
used incorrect terminology (e.g. call / invoke a SRB) and I apologize.
That said, AFAIK, there's really not much, save but for a RACROUTE
REQUEST=AUTH perhaps, that I could do
in terms of validation, I could do. Then again, even w/a RACROUTE/AUTH, it
still does not guarantee integrity.
All the above does is to make things a little harder for inappropriate
users. Perhaps that is all we can do ??.
I've taken everybody's suggestions and advice and think I've, decided to
take a slight variation to PC / SVC's, use
RACROUTE and have a separate load library that will be clearly documented as
needing to be APF'd.
Though I am responding to Shmuel, I thank everybody for taking the time to
respond / advice.
Once again, thank you everybody.
Kind Regards.
Jim Thomas
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Shmuel Metz (Seymour J.)
Sent: Sunday, December 01, 2013 5:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Un-authorized caller calling authorized services.
In <021001ceee3c$9f1fe880$dd5fb980$@TheThomasResidence.us>, on
11/30/2013
at 08:25 PM, Jim Thomas <j...@thethomasresidence.us> said:
In a nutshell, I'm trying to find out what the best way is for an
un-authorized called to call / invoke a SRB.
It can't. The only ways for unauthorized code to invoke authorized services
are PC and SVC. You need an interface service (either PC or
SVC) that will accept parameters, validity check everything and schedule the
SRB.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
