Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
I think that another major consideration not to encrypt programs is performance. Racf exits, for example, are not getting control of program calls. Pervasive encryption is done in bulks, programs may be called thousands of time during data processing. *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום א׳, 14 בינו׳ 2024 ב-1:38 מאת Seymour J Metz : > Off course they're files; they just aren't in EUnix file systems. Part of > the file contents for load modules is in the directory entries, and Fetch > relies on those data. As for program objects, if I knew they'd have to > shoot me; I don't have FAMS. > > The issue on STEPLIB is simply that IBM doesn't see a business case to > support it. Part of that support would be an update to APF and program > control for paths. Would you want individual executables in STEPLIB, or > only directories? RFE? > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> > Sent: Saturday, January 13, 2024 1:57 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > (PDSE format)? > > On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote: > > >I can imagine technical reason to not encrypt such libraries. > >However encryption is a kind of data protection. Data. Not programs. > > > But some load modules/program objects aren't really files. As Ifond > out to my dismay as a novice when I tried to use IEBGENER to copy > a load module to a different PDS. > > But UNIX program objects are "really files". "cp -p" works on then. > > But content Supervision relies heavily on the elaborate format. Part > of the reason that UNIX directories don't work in STEPLIB > concatenation. (Idea?) > > What about Format preserving encryption? > > Should the directory be encrypted likewise? > > What about driver-level encryption of virtual DASD? > > Unload it and encrypt the archive? > > What authority should be needed to use an encrypted program? > > > >W dniu 13.01.2024 o 17:28, Steve Estle pisze: > >> Everyone, > >> > >> Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and > despite the fact such functionality has been out for years by IBM to do > this, it is quite surprising how many software vendors when you contact > them they have no clue what you're talking about - that is a complete aside > - I'm not going to name vendors here but if you want some examples you can > contact me offline. > >> > >> My true reason for composing this is that we've discovered the > inability to encrypt load libraries - even in PDSE format. I've yet to get > a straight answer from IBM on why this is?... Is this a "giant" technical > hurdle for IBM? Or is it just cause there hasn't been anyone who raised > the need yet? If the latter does this capability interest others here if I > were to raise as an IBM idea - would you vote for it? > >> > >> I know this seems innocuous, but we'd like to encrypt as much as > possible in our environment and due to Top Secret deficiencies we have to > encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ > unfortunately). Given we have load module libraries under many differ > HLQ's this is posing difficulties in moving forward with our rollout when > an HLQ does have one or more load module libraries as part of that HLQ. > You can only imagine the pain of renaming a load library given all the JCL, > etc that is referencing that library name. > >> > >> Also, while encrypting load module libraries might seem a little far > fetched, there are of course many malicious viruses that have been launched > by injecting code into a suspecting piece of code. > >> > >> So two questions: > >> > >> 1. Why has IBM not already provided such functionality - can anyone > speak to the technical hurdles to provide? > >> 2. If I were to submit an IBM idea, can I count on this community for > some backing here to help in upvoting such an idea submission? > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Interesting discussion. Some thoughts. First, it's not "Pervasive Encryption" you're talking about. It's IBM z/OS data set encryption (DSE). PE is the IBM encryption strategy. When data set encryption came along, IBM kept calling it PE, but it's just part of PE (the rest of which hasn't really been that well defined, IMHO). Paul Gilmartin asked: >What about Format preserving encryption? Format-Preserving Encryption is for structured data, i.e., specific fields. You would not use it on a binary blob; at that point, you'd use XTS or one of the other AES modes whose output is the same length as the input. In fact, that leads me to wonder: what mode of AES *is* DSE using? It's AES, we know that, but it's unclear which mode. Since many modes increase the size of the data, I'm assuming it's a mode that does not increase the data size. Ah, this link (PDF): https://public.dhe.ibm.com/eserver/zseries/zos/DFSMS/ENCRYPTION/OA56622/OA56622.pdf suggests-though doesn't state explicitly-that it is indeed XTS, with the ability to switch to some other mode in the future if necessary (good design). Grant Taylor wrote, in part: >Conversely encryption is a kind of data authentication / verification. Um.not unless it's using specific AES modes, like GCM. If it's not expanding the data, there's nowhere to "fit" any kind of authentication. And per the above, I'm pretty sure it's (currently) XTS. He also noted: >Viruses (for PCs) have been self-decrypting for a long time. Sure, but there's some code getting invoked to do that. It's not magic. Still doesn't make it clear why DSE cannot do program objects. Attila Fogarasi suggests that the reason is simply because DSE requires extended-format data sets, which libraries aren't. That seems compelling. I assume the implicit rest of the story is, "IBM put the DSE code only in the extended-format data set processing code, because reasons". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
That "low level block processor" is Media Manager Services (MMS) and also SDM (System Data Mover) which is heavily used by all the performance oriented large volume data accessors (Db2, IMS, XRC,etc). On Sun, Jan 14, 2024 at 4:48 PM Seymour J Metz wrote: > There used to be a low level bock processor used by paging and VSAM, > operating on CI formatted data via STARTIO. I would guess that if it still > exists then Fetch uses it for program objects. > > For load modules it would still be CCWs, probably via STARTIO. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Tony Harminc > Sent: Saturday, January 13, 2024 11:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > (PDSE format)? > > On Sat, 13 Jan 2024 at 21:48, Seymour J Metz wrote: > > > Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a > > program object in DSFS to work. > > > > STEPLIB is a general facility, unrelated to HLASM. > > > I think he was referring to HLASM's use of directories for maclibs. > > > > It's essentially a tasklib provided by the Initiator and doesn't depend > on > > any access method. > > > > Surely it's not using CCWs against PDSEs? FAMS...? > > Tony H. > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > עַם יִשְׂרָאֵל חַי > > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > > > > From: IBM Mainframe Discussion List on behalf > > of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> > > Sent: Saturday, January 13, 2024 9:17 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > > (PDSE format)? > > > > On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote: > > > > > >The issue on STEPLIB is simply that IBM doesn't see a business case to > > support it. Part of that support would be an update to APF and program > > control for paths. Would you want individual executables in STEPLIB, or > > only directories? RFE? > > > > > Directories. Similar to the facilities provided for Assembler STEPLIB. > I > > suspect > > much of the accommodation was in access methods, not in HLASM. > > > > Can a program object in a DSFS be used equally by shell as an executable > > and by JCL EXEC PGM=? > > > > Does it receive a UNIX-like argc, argv[], envp[] or a CALL R1 plist, or > > it depends? > > > > Where's the DSFS User's Guide to answer such questions? > > > > > > > >From: Paul Gilmartin > > >Sent: Saturday, January 13, 2024 1:57 PM > > > > > >But UNIX program objects are "really files". "cp -p" works on then. > > > > > >But content Supervision relies heavily on the elaborate format. Part > > >of the reason that UNIX directories don't work in STEPLIB > > >concatenation. (Idea?) > > > > -- > > gil > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Is the problem that they cannot be encrypted or that they cannot be executed when in encrypted format? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
It is indeed a technical reason: PDS and PDSE datasets cannot be Extended-Format. Pervasive Encryption requires Extended-Format. The restrictions on Extended-Format have been problematic for the past decade, so presumably not easy to fix. A few other dataset types are also affected (such as Direct). Your problem is more with the use of HLQ to designate Pervasive Encryption, that is maybe much easier to fix (at a guess). On Sun, Jan 14, 2024 at 3:29 AM Steve Estle wrote: > Everyone, > > Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and > despite the fact such functionality has been out for years by IBM to do > this, it is quite surprising how many software vendors when you contact > them they have no clue what you're talking about - that is a complete aside > - I'm not going to name vendors here but if you want some examples you can > contact me offline. > > My true reason for composing this is that we've discovered the inability > to encrypt load libraries - even in PDSE format. I've yet to get a > straight answer from IBM on why this is?... Is this a "giant" technical > hurdle for IBM? Or is it just cause there hasn't been anyone who raised > the need yet? If the latter does this capability interest others here if I > were to raise as an IBM idea - would you vote for it? > > I know this seems innocuous, but we'd like to encrypt as much as possible > in our environment and due to Top Secret deficiencies we have to encrypt at > high level qualifier level (HLQ) (all or nothing under each HLQ > unfortunately). Given we have load module libraries under many differ > HLQ's this is posing difficulties in moving forward with our rollout when > an HLQ does have one or more load module libraries as part of that HLQ. > You can only imagine the pain of renaming a load library given all the JCL, > etc that is referencing that library name. > > Also, while encrypting load module libraries might seem a little far > fetched, there are of course many malicious viruses that have been launched > by injecting code into a suspecting piece of code. > > So two questions: > > 1. Why has IBM not already provided such functionality - can anyone speak > to the technical hurdles to provide? > 2. If I were to submit an IBM idea, can I count on this community for some > backing here to help in upvoting such an idea submission? > > Thanks for your indulgence, > > Steve Estle > sest...@gmail.com > Peraton systems programmer > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
There used to be a low level bock processor used by paging and VSAM, operating on CI formatted data via STARTIO. I would guess that if it still exists then Fetch uses it for program objects. For load modules it would still be CCWs, probably via STARTIO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Saturday, January 13, 2024 11:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? On Sat, 13 Jan 2024 at 21:48, Seymour J Metz wrote: > Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a > program object in DSFS to work. > > STEPLIB is a general facility, unrelated to HLASM. I think he was referring to HLASM's use of directories for maclibs. > It's essentially a tasklib provided by the Initiator and doesn't depend on > any access method. > Surely it's not using CCWs against PDSEs? FAMS...? Tony H. > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> > Sent: Saturday, January 13, 2024 9:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > (PDSE format)? > > On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote: > > > >The issue on STEPLIB is simply that IBM doesn't see a business case to > support it. Part of that support would be an update to APF and program > control for paths. Would you want individual executables in STEPLIB, or > only directories? RFE? > > > Directories. Similar to the facilities provided for Assembler STEPLIB. I > suspect > much of the accommodation was in access methods, not in HLASM. > > Can a program object in a DSFS be used equally by shell as an executable > and by JCL EXEC PGM=? > > Does it receive a UNIX-like argc, argv[], envp[] or a CALL R1 plist, or > it depends? > > Where's the DSFS User's Guide to answer such questions? > > > > >From: Paul Gilmartin > >Sent: Saturday, January 13, 2024 1:57 PM > > > >But UNIX program objects are "really files". "cp -p" works on then. > > > >But content Supervision relies heavily on the elaborate format. Part > >of the reason that UNIX directories don't work in STEPLIB > >concatenation. (Idea?) > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On Sat, 13 Jan 2024 at 21:48, Seymour J Metz wrote: > Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a > program object in DSFS to work. > > STEPLIB is a general facility, unrelated to HLASM. I think he was referring to HLASM's use of directories for maclibs. > It's essentially a tasklib provided by the Initiator and doesn't depend on > any access method. > Surely it's not using CCWs against PDSEs? FAMS...? Tony H. > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Discussion List on behalf > of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> > Sent: Saturday, January 13, 2024 9:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries > (PDSE format)? > > On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote: > > > >The issue on STEPLIB is simply that IBM doesn't see a business case to > support it. Part of that support would be an update to APF and program > control for paths. Would you want individual executables in STEPLIB, or > only directories? RFE? > > > Directories. Similar to the facilities provided for Assembler STEPLIB. I > suspect > much of the accommodation was in access methods, not in HLASM. > > Can a program object in a DSFS be used equally by shell as an executable > and by JCL EXEC PGM=? > > Does it receive a UNIX-like argc, argv[], envp[] or a CALL R1 plist, or > it depends? > > Where's the DSFS User's Guide to answer such questions? > > > > >From: Paul Gilmartin > >Sent: Saturday, January 13, 2024 1:57 PM > > > >But UNIX program objects are "really files". "cp -p" works on then. > > > >But content Supervision relies heavily on the elaborate format. Part > >of the reason that UNIX directories don't work in STEPLIB > >concatenation. (Idea?) > > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Unless IBM has enhanced z/OS to allow EXEC PGM=path, I wouldn't expect a program object in DSFS to work. STEPLIB is a general facility, unrelated to HLASM. It's essentially a tasklib provided by the Initiator and doesn't depend on any access method. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Saturday, January 13, 2024 9:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote: > >The issue on STEPLIB is simply that IBM doesn't see a business case to support >it. Part of that support would be an update to APF and program control for >paths. Would you want individual executables in STEPLIB, or only directories? >RFE? > Directories. Similar to the facilities provided for Assembler STEPLIB. I suspect much of the accommodation was in access methods, not in HLASM. Can a program object in a DSFS be used equally by shell as an executable and by JCL EXEC PGM=? Does it receive a UNIX-like argc, argv[], envp[] or a CALL R1 plist, or it depends? Where's the DSFS User's Guide to answer such questions? > >From: Paul Gilmartin >Sent: Saturday, January 13, 2024 1:57 PM > >But UNIX program objects are "really files". "cp -p" works on then. > >But content Supervision relies heavily on the elaborate format. Part >of the reason that UNIX directories don't work in STEPLIB >concatenation. (Idea?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On Sat, 13 Jan 2024 23:38:23 +, Seymour J Metz wrote: > >The issue on STEPLIB is simply that IBM doesn't see a business case to support >it. Part of that support would be an update to APF and program control for >paths. Would you want individual executables in STEPLIB, or only directories? >RFE? > Directories. Similar to the facilities provided for Assembler STEPLIB. I suspect much of the accommodation was in access methods, not in HLASM. Can a program object in a DSFS be used equally by shell as an executable and by JCL EXEC PGM=? Does it receive a UNIX-like argc, argv[], envp[] or a CALL R1 plist, or it depends? Where's the DSFS User's Guide to answer such questions? > >From: Paul Gilmartin >Sent: Saturday, January 13, 2024 1:57 PM > >But UNIX program objects are "really files". "cp -p" works on then. > >But content Supervision relies heavily on the elaborate format. Part >of the reason that UNIX directories don't work in STEPLIB >concatenation. (Idea?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
My gues is that low level services used by Fetch, e.g., EXCP, STARTIO, do not support pervasive encryption. What about windowed access to VSAM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Estle Sent: Saturday, January 13, 2024 11:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? Everyone, Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and despite the fact such functionality has been out for years by IBM to do this, it is quite surprising how many software vendors when you contact them they have no clue what you're talking about - that is a complete aside - I'm not going to name vendors here but if you want some examples you can contact me offline. My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. I've yet to get a straight answer from IBM on why this is?... Is this a "giant" technical hurdle for IBM? Or is it just cause there hasn't been anyone who raised the need yet? If the latter does this capability interest others here if I were to raise as an IBM idea - would you vote for it? I know this seems innocuous, but we'd like to encrypt as much as possible in our environment and due to Top Secret deficiencies we have to encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ unfortunately). Given we have load module libraries under many differ HLQ's this is posing difficulties in moving forward with our rollout when an HLQ does have one or more load module libraries as part of that HLQ. You can only imagine the pain of renaming a load library given all the JCL, etc that is referencing that library name. Also, while encrypting load module libraries might seem a little far fetched, there are of course many malicious viruses that have been launched by injecting code into a suspecting piece of code. So two questions: 1. Why has IBM not already provided such functionality - can anyone speak to the technical hurdles to provide? 2. If I were to submit an IBM idea, can I count on this community for some backing here to help in upvoting such an idea submission? Thanks for your indulgence, Steve Estle sest...@gmail.com Peraton systems programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Programs are data. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> Sent: Saturday, January 13, 2024 12:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? I can imagine technical reason to not encrypt such libraries. However encryption is a kind of data protection. Data. Not programs. -- Radoslaw Skorupka Lodz, Poland W dniu 13.01.2024 o 17:28, Steve Estle pisze: > Everyone, > > Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and > despite the fact such functionality has been out for years by IBM to do this, > it is quite surprising how many software vendors when you contact them they > have no clue what you're talking about - that is a complete aside - I'm not > going to name vendors here but if you want some examples you can contact me > offline. > > My true reason for composing this is that we've discovered the inability to > encrypt load libraries - even in PDSE format. I've yet to get a straight > answer from IBM on why this is?... Is this a "giant" technical hurdle for > IBM? Or is it just cause there hasn't been anyone who raised the need yet? > If the latter does this capability interest others here if I were to raise as > an IBM idea - would you vote for it? > > I know this seems innocuous, but we'd like to encrypt as much as possible in > our environment and due to Top Secret deficiencies we have to encrypt at high > level qualifier level (HLQ) (all or nothing under each HLQ unfortunately). > Given we have load module libraries under many differ HLQ's this is posing > difficulties in moving forward with our rollout when an HLQ does have one or > more load module libraries as part of that HLQ. You can only imagine the > pain of renaming a load library given all the JCL, etc that is referencing > that library name. > > Also, while encrypting load module libraries might seem a little far fetched, > there are of course many malicious viruses that have been launched by > injecting code into a suspecting piece of code. > > So two questions: > > 1. Why has IBM not already provided such functionality - can anyone speak to > the technical hurdles to provide? > 2. If I were to submit an IBM idea, can I count on this community for some > backing here to help in upvoting such an idea submission? > > Thanks for your indulgence, > > Steve Estle > sest...@gmail.com > Peraton systems programmer > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Off course they're files; they just aren't in EUnix file systems. Part of the file contents for load modules is in the directory entries, and Fetch relies on those data. As for program objects, if I knew they'd have to shoot me; I don't have FAMS. The issue on STEPLIB is simply that IBM doesn't see a business case to support it. Part of that support would be an update to APF and program control for paths. Would you want individual executables in STEPLIB, or only directories? RFE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Saturday, January 13, 2024 1:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote: >I can imagine technical reason to not encrypt such libraries. >However encryption is a kind of data protection. Data. Not programs. > But some load modules/program objects aren't really files. As Ifond out to my dismay as a novice when I tried to use IEBGENER to copy a load module to a different PDS. But UNIX program objects are "really files". "cp -p" works on then. But content Supervision relies heavily on the elaborate format. Part of the reason that UNIX directories don't work in STEPLIB concatenation. (Idea?) What about Format preserving encryption? Should the directory be encrypted likewise? What about driver-level encryption of virtual DASD? Unload it and encrypt the archive? What authority should be needed to use an encrypted program? >W dniu 13.01.2024 o 17:28, Steve Estle pisze: >> Everyone, >> >> Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and >> despite the fact such functionality has been out for years by IBM to do >> this, it is quite surprising how many software vendors when you contact them >> they have no clue what you're talking about - that is a complete aside - I'm >> not going to name vendors here but if you want some examples you can contact >> me offline. >> >> My true reason for composing this is that we've discovered the inability to >> encrypt load libraries - even in PDSE format. I've yet to get a straight >> answer from IBM on why this is?... Is this a "giant" technical hurdle for >> IBM? Or is it just cause there hasn't been anyone who raised the need yet? >> If the latter does this capability interest others here if I were to raise >> as an IBM idea - would you vote for it? >> >> I know this seems innocuous, but we'd like to encrypt as much as possible in >> our environment and due to Top Secret deficiencies we have to encrypt at >> high level qualifier level (HLQ) (all or nothing under each HLQ >> unfortunately). Given we have load module libraries under many differ HLQ's >> this is posing difficulties in moving forward with our rollout when an HLQ >> does have one or more load module libraries as part of that HLQ. You can >> only imagine the pain of renaming a load library given all the JCL, etc that >> is referencing that library name. >> >> Also, while encrypting load module libraries might seem a little far >> fetched, there are of course many malicious viruses that have been launched >> by injecting code into a suspecting piece of code. >> >> So two questions: >> >> 1. Why has IBM not already provided such functionality - can anyone speak to >> the technical hurdles to provide? >> 2. If I were to submit an IBM idea, can I count on this community for some >> backing here to help in upvoting such an idea submission? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
IBM/MS-DOS 6 stored compressed programs by having a decompression stub and the compressed program as the remainder of the file data. On Sat, Jan 13, 2024 at 1:50 PM Grant Taylor < 023065957af1-dmarc-requ...@listserv.ua.edu> wrote: > On 1/13/24 13:39, Gibney, Dave wrote: > > It should be obvious, but as a practical matter, you can't encrypt > > the modules that do the decryption and it also follows that you can't > > encrypt the modules that provide the execution environment (z/OS) > > for these modules. > > I would like to agree with you. > > Viruses (for PCs) have been self-decrypting for a long time. > > Given how people espouse that the mainframe can do everything that a PC > can do ... I think it stands to reason that someone with sufficient > motivation /could/ write a mainframe program that would decrypt itself. > > If we accept that it's hypothetically possible to write a mainframe > program that can decrypt itself, then could we also accept the > hypothetical possibility to do the same with a program that is part of > the OS? > > It's been a very long time since I've looked at low level mainframe OS > IPL / boot strap methods and procedures. But I'm confident that the > first part of the program that IPLs off of DASD doesn't know how to do > most of what the OS ultimately does. > > It's all about have just enough recognizable -> executable code that can > decode / decrypt more recognizable -> executable code that can decrypt > even more. > > Hence in /concept/ I don't agree with you. > > > > -- > Grant. . . . > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Direct branch entry to ICSF routines
Out of curiosity, does that means that the CSFDLL functions do not create a linkage stack entry before calling the true routines/ On Fri, 12 Jan 2024 14:23:54 + Eric D Rossman wrote: :>There is no documentation because this is not a supported interface. It has been suggested in passing but has never been put forward as an official requirement. :>All LE-capable applications have access to the CSFDLLxx (where xx is 31,3X,64) libraries and the csfbext.h C/C++ header to call directly :>All non-LE applications have the CSN* and CSN*6 (plus CSF*/CSF*6) assembler stubs. :>Eric Rossman :>ICSF Architect :>-Original Message- :>From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen :>Sent: Friday, January 12, 2024 3:26 AM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: [EXTERNAL] Direct branch entry to ICSF routines :>I have been looking but I have not yet found the explicit doc that shows how to call ICSF routines via the CSFCCVT. :>Looking at a few of the stub routines I see that they create a linkage stack entry and then call the real routine via CSFCCVT but the labels in the CSFCCVT are not obviously related to the name of the stub routine. :>I am expecting to find something like for the name/token routines, where the stub can be used but the direct entry is also documented. :>Further research shows that the several routine that I am interested all branch to the same EP, but the stub loads a different value into R0. Don't ask me why there aren't a list of equated values for the various functions and a parameter with the function code. At any rate, high level language routines cannot set R0 but assembler routines certainly can. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On 1/13/24 13:39, Gibney, Dave wrote: It should be obvious, but as a practical matter, you can't encrypt the modules that do the decryption and it also follows that you can't encrypt the modules that provide the execution environment (z/OS) for these modules. I would like to agree with you. Viruses (for PCs) have been self-decrypting for a long time. Given how people espouse that the mainframe can do everything that a PC can do ... I think it stands to reason that someone with sufficient motivation /could/ write a mainframe program that would decrypt itself. If we accept that it's hypothetically possible to write a mainframe program that can decrypt itself, then could we also accept the hypothetical possibility to do the same with a program that is part of the OS? It's been a very long time since I've looked at low level mainframe OS IPL / boot strap methods and procedures. But I'm confident that the first part of the program that IPLs off of DASD doesn't know how to do most of what the OS ultimately does. It's all about have just enough recognizable -> executable code that can decode / decrypt more recognizable -> executable code that can decrypt even more. Hence in /concept/ I don't agree with you. -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
It should be obvious, but as a practical matter, you can't encrypt the modules that do the decryption and it also follows that you can't encrypt the modules that provide the execution environment (z/OS) for these modules. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On 1/13/24 11:06, Radoslaw Skorupka wrote: However encryption is a kind of data protection. Conversely encryption is a kind of data authentication / verification. Data. Not programs. Programs are special data used to manipulate / act on other data. -- Grant. . . . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On Sat, 13 Jan 2024 18:06:24 +0100, Radoslaw Skorupka wrote: >I can imagine technical reason to not encrypt such libraries. >However encryption is a kind of data protection. Data. Not programs. > But some load modules/program objects aren't really files. As Ifond out to my dismay as a novice when I tried to use IEBGENER to copy a load module to a different PDS. But UNIX program objects are "really files". "cp -p" works on then. But content Supervision relies heavily on the elaborate format. Part of the reason that UNIX directories don't work in STEPLIB concatenation. (Idea?) What about Format preserving encryption? Should the directory be encrypted likewise? What about driver-level encryption of virtual DASD? Unload it and encrypt the archive? What authority should be needed to use an encrypted program? >W dniu 13.01.2024 o 17:28, Steve Estle pisze: >> Everyone, >> >> Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and >> despite the fact such functionality has been out for years by IBM to do >> this, it is quite surprising how many software vendors when you contact them >> they have no clue what you're talking about - that is a complete aside - I'm >> not going to name vendors here but if you want some examples you can contact >> me offline. >> >> My true reason for composing this is that we've discovered the inability to >> encrypt load libraries - even in PDSE format. I've yet to get a straight >> answer from IBM on why this is?... Is this a "giant" technical hurdle for >> IBM? Or is it just cause there hasn't been anyone who raised the need yet? >> If the latter does this capability interest others here if I were to raise >> as an IBM idea - would you vote for it? >> >> I know this seems innocuous, but we'd like to encrypt as much as possible in >> our environment and due to Top Secret deficiencies we have to encrypt at >> high level qualifier level (HLQ) (all or nothing under each HLQ >> unfortunately). Given we have load module libraries under many differ HLQ's >> this is posing difficulties in moving forward with our rollout when an HLQ >> does have one or more load module libraries as part of that HLQ. You can >> only imagine the pain of renaming a load library given all the JCL, etc that >> is referencing that library name. >> >> Also, while encrypting load module libraries might seem a little far >> fetched, there are of course many malicious viruses that have been launched >> by injecting code into a suspecting piece of code. >> >> So two questions: >> >> 1. Why has IBM not already provided such functionality - can anyone speak to >> the technical hurdles to provide? >> 2. If I were to submit an IBM idea, can I count on this community for some >> backing here to help in upvoting such an idea submission? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
1. Restrictions for encrypted data sets - System data sets (such as Catalogs, SMS control data sets, SHCDS, HSM data sets) must not be encrypted, unless otherwise specified in product documentation. - Data sets used during IPL must not be encrypted. Page 5 https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R5izsp100/$file/izsp100_v2r5.pdf Joe On Sat, Jan 13, 2024 at 11:06 AM Radoslaw Skorupka < 0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > I can imagine technical reason to not encrypt such libraries. > However encryption is a kind of data protection. Data. Not programs. > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > W dniu 13.01.2024 o 17:28, Steve Estle pisze: > > Everyone, > > > > Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and > despite the fact such functionality has been out for years by IBM to do > this, it is quite surprising how many software vendors when you contact > them they have no clue what you're talking about - that is a complete aside > - I'm not going to name vendors here but if you want some examples you can > contact me offline. > > > > My true reason for composing this is that we've discovered the inability > to encrypt load libraries - even in PDSE format. I've yet to get a > straight answer from IBM on why this is?... Is this a "giant" technical > hurdle for IBM? Or is it just cause there hasn't been anyone who raised > the need yet? If the latter does this capability interest others here if I > were to raise as an IBM idea - would you vote for it? > > > > I know this seems innocuous, but we'd like to encrypt as much as > possible in our environment and due to Top Secret deficiencies we have to > encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ > unfortunately). Given we have load module libraries under many differ > HLQ's this is posing difficulties in moving forward with our rollout when > an HLQ does have one or more load module libraries as part of that HLQ. > You can only imagine the pain of renaming a load library given all the JCL, > etc that is referencing that library name. > > > > Also, while encrypting load module libraries might seem a little far > fetched, there are of course many malicious viruses that have been launched > by injecting code into a suspecting piece of code. > > > > So two questions: > > > > 1. Why has IBM not already provided such functionality - can anyone > speak to the technical hurdles to provide? > > 2. If I were to submit an IBM idea, can I count on this community for > some backing here to help in upvoting such an idea submission? > > > > Thanks for your indulgence, > > > > Steve Estle > > sest...@gmail.com > > Peraton systems programmer > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
I can imagine technical reason to not encrypt such libraries. However encryption is a kind of data protection. Data. Not programs. -- Radoslaw Skorupka Lodz, Poland W dniu 13.01.2024 o 17:28, Steve Estle pisze: Everyone, Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and despite the fact such functionality has been out for years by IBM to do this, it is quite surprising how many software vendors when you contact them they have no clue what you're talking about - that is a complete aside - I'm not going to name vendors here but if you want some examples you can contact me offline. My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. I've yet to get a straight answer from IBM on why this is?... Is this a "giant" technical hurdle for IBM? Or is it just cause there hasn't been anyone who raised the need yet? If the latter does this capability interest others here if I were to raise as an IBM idea - would you vote for it? I know this seems innocuous, but we'd like to encrypt as much as possible in our environment and due to Top Secret deficiencies we have to encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ unfortunately). Given we have load module libraries under many differ HLQ's this is posing difficulties in moving forward with our rollout when an HLQ does have one or more load module libraries as part of that HLQ. You can only imagine the pain of renaming a load library given all the JCL, etc that is referencing that library name. Also, while encrypting load module libraries might seem a little far fetched, there are of course many malicious viruses that have been launched by injecting code into a suspecting piece of code. So two questions: 1. Why has IBM not already provided such functionality - can anyone speak to the technical hurdles to provide? 2. If I were to submit an IBM idea, can I count on this community for some backing here to help in upvoting such an idea submission? Thanks for your indulgence, Steve Estle sest...@gmail.com Peraton systems programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Everyone, Our team is knee deep into pervasive encryption rollout on ZOS 2.5 and despite the fact such functionality has been out for years by IBM to do this, it is quite surprising how many software vendors when you contact them they have no clue what you're talking about - that is a complete aside - I'm not going to name vendors here but if you want some examples you can contact me offline. My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. I've yet to get a straight answer from IBM on why this is?... Is this a "giant" technical hurdle for IBM? Or is it just cause there hasn't been anyone who raised the need yet? If the latter does this capability interest others here if I were to raise as an IBM idea - would you vote for it? I know this seems innocuous, but we'd like to encrypt as much as possible in our environment and due to Top Secret deficiencies we have to encrypt at high level qualifier level (HLQ) (all or nothing under each HLQ unfortunately). Given we have load module libraries under many differ HLQ's this is posing difficulties in moving forward with our rollout when an HLQ does have one or more load module libraries as part of that HLQ. You can only imagine the pain of renaming a load library given all the JCL, etc that is referencing that library name. Also, while encrypting load module libraries might seem a little far fetched, there are of course many malicious viruses that have been launched by injecting code into a suspecting piece of code. So two questions: 1. Why has IBM not already provided such functionality - can anyone speak to the technical hurdles to provide? 2. If I were to submit an IBM idea, can I count on this community for some backing here to help in upvoting such an idea submission? Thanks for your indulgence, Steve Estle sest...@gmail.com Peraton systems programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HEALTH CHECKER (USS_FILESYS_CONFIG)
You originally asked about the syntax error message. The syntax of the command used was incorrect, and I think the syntax error message was pretty reasonable. F HZSPROC,ADDREPLACE,CHECK=(IBMUSS,USS_HFS_DETECTED),USS=YES ASA101I SYNTAX ERROR: WAS SEEN, WHERE ONE OF 826 (CHECKROUTINE DATE EXEC INTERVAL REASON SEVERITY) WOULD BE CORRECT. DETECTING MODULE IS HZSIPMX It is telling you that it reached the end of the command, and you had omitted something required, which depending on what you were doing would be one of the keywords mentioned. But you should not be trying to "add" the check, because you have no idea how to do so. And you cannot "enable" a check by a command; you have to address the problem by fixing the environmental problem. As you show the problem is that the system does not think that you have USS enabled (or at least that was the case when the check ran). You will have to determine why that is the case. If USS is enabled, you might have to ask that the check be run again (its default interval is 24 hours; I don't recall if checks disabled waiting for USS get run automatically if USS becomes enabled). Those who suggested "E" or "Enable" might have been thinking of activate (rather than enable). Peter Relsonz/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Traversing The Linkage Stack
>From one of the posts, it wasn't clear if the OP realized that the entry >descriptor is at the end of the entry, not at the beginning. If you're not traversing stack sections, complications related to header and trailer don't tend to come into play. Consider posting the entire linkage stack from start through time of error, along with the data from the SDWA which the OP indicates is not in the linkage stack. Unlike AI, RTM does not make stuff up. If there is a PSW, RTM found it somewhere, either in an RB/XSB or the linkage stack. If there is a problem marking the PSW as "from a linkage stack entry", that would be good to know. And for that, the information I mentioned above (plus all the data from the RBs/XSBs) would be needed for diagnosis. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
