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 <sme...@gmu.edu>: > 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Paul Gilmartin <0000042bfe9c879d-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 instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
