Rob - How about: If your authorized program while executing in PSW Key
0-7 stores into an address provided by an unauthorized caller (as long
as the store operation uses the execution PSW KEY) then this is a
violation of the IBM statement of integrity.
Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007
On 3/8/2012 13:02 PM, Rob Scott wrote:
1) If your authorized program while executing in PSW key 0-7 stores
into an address provided by an unauthorized caller then this is a violation of
the IBM statement of integrity.
Sorry - I disagree with this.
It is quite OK for auth routines (eg PC-ss) to store into storage whose address
is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the
data.
See the MVCDK instruction.
Likewise any authorized routine should treat caller provided storage with
suspicion and use MVCSK to copy any data from the caller and use trusted
control block pointers rather than rely on caller contents.
Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Ray Overby
Sent: 08 March 2012 18:46
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!
Charles - yes, it is somewhat ambiguous what "violation of the IBM statement of
integrity" means. Perhaps some Integrity Vulnerability examples will help clarify:
1) If your authorized program while executing in PSW key 0-7 stores
into an address provided by an unauthorized caller then this is a violation of
the IBM statement of integrity.
2) If your authorized program while executing in PSW Key 0-7 or
supervisor state branches to an address provided by an unauthorized requester
then this is a violation of the IBM statement of Integrity.
3) If your authorized program while executing in PSW Key 0-7 or
supervisor state returns control to an unauthorized requester in an authorized
state then this is a violation of the IBM statement of Integrity. By authorized
state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET.
4) If your authorized program while executing in PSW Key 0-7 copies
fetch protected storage to non-fetch protected storage then this is a violation
of the IBM statement of integrity.
The "unauthorized requester" in these case's would be any PSW Key 8 problem
state program that is not currently enabled to MODESET prior to issuing a request to an
authorized service. After the request completes the program now has new capabilities that
were not available prior to the request such as:
- The program could now be in an authorized state (psw key 0-7 or
supervisor state)
- The program could now have the ability to MODESET
- The security credentials may have been dynamically elevated (i.e. -
I now have RACF privileged attribute which I did not have before)
- Some code provided by my program could have been executed in an
authorized state (PSW Key 0-7 or Supervisor state).
If you examine the before and after state around the invoking of the authorized
service you generally see some form of elevated capabilities when a violation
of the IBM statement of integrity occurs.
Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM) www.zassure.com
(312)574-0007
On 3/8/2012 11:20 AM, Charles Mills wrote:
I will give it one more shot at trying to clarify what I mean.
Witness this thread, reasonable people can disagree on what "violates
the statement of integrity" means. One person's reasonable or only
available technique is another person's violation.
We could use some finer granularity. We could use a standard statement
of "does X but does not do Y."
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Ray Overby
Sent: Thursday, March 08, 2012 8:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!
The IBM statement of Integrity or its equivalent is a standard that
all authorized programs should conform with. See IBM statement of
Integrity
<http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_st
atemen
t.html>.
If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide:
21.1.2
<http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?
ACTION=MATCHES&REQUEST=system+integrity&TYPE=FUZZY&SHELF=EZ2ZBK0K&DT=2
010062
9141054&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank
=RANK&
ScrollTOP=FIRSTHIT#FIRSTHIT>/you/
will see that IBM puts the responsibility on the installation for
ensuring the integrity (i.e. - conforms to the IBM statement of
Integrity) for any modifications or extensions to z/OS the
installation makes. This would include any authorized code
written/installed by the installation as well as any authorized code installed
that is from ISVs.
If the backdoor, intercept, or other authorized program violates the
IBM statement of integrity then it is a problem that needs to be remediated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
