Radek, the only thing that was inherited that I think could reasonable change is the 24-byte DES MK enablement. The rest of the ACPs are behaving the way I think they should. I was there when the deep magic was written.
Eric Rossman --------------------------------- ICSF Security Architect z/OS Security --------------------------------- -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Radoslaw Skorupka Sent: Saturday, July 5, 2025 7:57 PM To: [email protected] Subject: [EXTERNAL] Re: ICSF ACP and TKE 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
