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_statement.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=20100629141054&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.
Ray Overby
Key Resources, Inc.
Ensuring System Integrity for z/Series^(TM)
www.zassure.com
(312)574-0007
On 3/8/2012 08:40 AM, Charles Mills wrote:
an APF authorized program can do that. It can also create a "backdoor"
(my definition) that
any task in the system can walk through and get into supervisor state.
That is the objection that was raised, and it is a very different matter.
I should be smarter than to wade into this one but is it not true,
unfortunately, that an APF program can do ANYTHING it wants to do? "Doing
anything it wants to do" would include "granting privileges implicitly to
other programs" would it not?
Further, there is no industry agreement -- witness this thread -- on what
constitutes acceptable APF authorized program conduct. My "the only
technique that will work" is someone else's "criminal breach of security."
It seems to me the problem here is, from a technological point of view, the
"all or nothing" nature of APF authorization. IBM is moving away from that
approach, but APF authorization as it is and was is going to be with us for
a long time. From a non-technology point of view, we need some sort of
industry agreement on what is good behavior in an authorized program. I am
thinking of something like a standardized set of questions that a vendor
could answer and have an officer certify: "Mr./Ms. Customer, we are asking
for APF authorization. I certify under penalty of fraud that our program
uses APF authorization to do X, and Y, and Z but does not do A, and B, and
C."
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Tom Marchant
Sent: Thursday, March 08, 2012 6:19 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Program FLIH backdoor - This is a criminal breach of security!
On Thu, 8 Mar 2012 13:49:28 +0000, Pate, Gene wrote:
You have your definition for 'backdoor', I have mine, Next.
That is the root of your confusion. This thread is about a vendor creating
a backdoor according to my definition. You are "amazed at the uproar over
this"
because you applied your definition of what a "backdoor"
is without considering the description of what the backdoor was in the
original discussion.
if they were APF authorized then they could by definition switch anyone
or any task in the system to supervisor state
Yes, an APF authorized program can do that. It can also create a "backdoor"
(my definition) that any task in the system can walk through and get into
supervisor state. That is the objection that was raised, and it is a very
different matter.
----------------------------------------------------------------------
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
