Some clarifications:
1. Radek. Call me Radek. :-) Radosław is official form and hard to
pronounce by Englishmen. ;-)
2. I don't have a problem. I just want to *understand* it. Now it seems
to me it is not rational, it is rather inheritance of very old days and
very different, long time ago forgotten setup. However instead of
impression I'd like to know the facts. That's all.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 05.07.2025 o 21:30, Lennie Bradshaw pisze:
Bill,
I was not suggesting that zPDT is anything other than what it is. I was merely
stating what exists. There is no possibility of a TKE for a zPDT but I am
nevertheless glad to be able to change some Access Control Points for testing
purposes.
Radoslaw wishes to alter some of the Access Control Points on his real system
but has no TKE.
Nothing I have said was intended as any criticism of zPDT policy, nor was I
stating that security on a zPDT is anything special. Basically, it is a Linux
system and relies on Linux security for almost everything.
Lennie
-----Original Message-----
From: IBM Mainframe Discussion List<[email protected]> On Behalf
[email protected]
Sent: 05 July 2025 16:38
To:[email protected]
Subject: Re: ICSF ACP and TKE
I run a zPDT and on there is a utility (i.e. a Linux command ACPTOOL) to allow
the changing of some Control Points without a TKE.....
As has been stated multiple times in the zPDT documentation (RedBooks and
BlueBook) and on the zPDT forum: zPDT is not intended as a secure system for
many reasons. There are no plans to change this on an emulated system!!
There is an intent to have most of the ICSF commands/macros (and actual hardware instructions)
"work" to provide program development and testing, but that is a different intent than
providing a "real" secure system. (And one specific recommendation has been repeated: DO
NOT USE THE SAME MASTER KEYS ON zPDT THAT ARE USED ON A REAL SYSTEM.)
It seems to me (being old and a little stupid) that there are several levels to
this discussion:
1.
Those having almost no interest in security much beyond simple userids and some basic
dataset protections. Many zPDT users, or perhaps real system/LPAR users who are
sufficiently isolated by other means are in this group. This might include a potentially
larger group of "newcomers" to mainframes!!
2.
Those who would like to go through the motions (without digging too far into the details)
to implement some basic security, mostly to protect against "accidental"
errors/problems/trials/experimentation/etc. This level would probably involve some
routine basic/simple maintenance such as normal RACF commands, etc, etc, etc.
3.
Those who really need much fuller security and are willing to dig into many
details. These might be installations that process $$billions$$ daily, etc,
etc, etc, and need to immediately consider quantum-safe details, etc, etc. Or
those who are developing software products to work in this environment.
4.
Those dealing with other security natures (such as national Top Secret, etc,
etc) and need to incorporate their systems into the appropriate
level/compartment/etc. (The IBM-MAIN discussions do not generally involve such
systems, so I will ignore them here!)
In the good-old-days, when I was a little younger, there were often smaller RedBooks that dealt
with practical usage of various areas of IBM systems. In a sense, this material was mostly written
by actual users (customers, IBMers) of the products being addressed and often touched multiple IBM
products/commands/components that were involved in practical operations. These were sometimes seen
as "hands on" books. (Of course, since today few companies provide real "paper"
books, there are additional considerations .....)
My $.02 worth, if it is worth that much!
Bill Ogden
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
