Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
We don't have to encourage incorrect usage. We should fight back against such inanity. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Phil Smith III Sent: Wednesday, January 17, 2024 3:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? Radoslaw Skorupka wrote, in part: >"security by obscurity" means just the key under the mat. I'd agree that it perhaps SHOULD mean that, but that isn't how people use the term. -- 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)?
Radoslaw Skorupka wrote, in part: >"security by obscurity" means just the key under the mat. I'd agree that it perhaps SHOULD mean that, but that isn't how people use the term. And even then, I'd submit that that's just another trivial case of "if you have enough": you have to know/think to look under the mat. ObAnecdote: 35+ years ago, at a tiny vendor, we took a power hit and the room didn't come back up. Eventually I convinced myself the room still didn't have power, so I called the power company. By this point it's 2AM. Power guy comes, is cheerful, needs to get into room with main breaker. Door is locked. I ask if he has a sledgehammer; he says sure, but HE'S not about to smash the doorknob. No, I say, I'll do it. Building isn't supposed to have us locked out, we have a company to run, a $10 doorknob is a perfectly reasonable price to pay. So I bash the knob and he fixes the problem (a half-tripped breaker). Next day I go down to tell the building guy what happened. He listens, laughs-and reaches up to the top of the doorframe, pulls down a key. So we had security by obscurity AND the XKCD both more or less exemplified in one incident! (OK, we were smashing a door with a hammer, not hitting a guy with a wrench, but close enough.) -- 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)?
Gentlemen, Let me chime in Password are to be kept secret. Encryption keys (except public ones) are to be kept secret. This is widely known and quite obvious IMHO. Lost/disclosed password is more or less like lost door key. (Assuming no MFA, where the password is only one of several "keys"). However there is also "key under the mat" aka backdoor or vulnerability. This is also a secret, but IMHO completely different thing. For regular access the method is know and documented with the requirement to keep the key secret. For key under the windshield wiper everyone who know the method can enter. And the term "security by obscurity" means just the key under the mat. Unrestricted (or poorly restricted) access, but not documented. A backdoor by definition is undocumented access with no need to have valid password or encryption key. My €_0.02_ -- Radoslaw Skorupka Lodz, Poland W dniu 16.01.2024 o 23:22, Phil Smith III pisze: Paul Gilmartin wrote: I believe otherwise. I know of a case where a vendor allowed a product to escape to the field containing a tester's back door, and another related to II14489. Either could be exploited with no brute force, merely knowledge of the existence and nature of the defect. In the case of the latter, the vendor chose to obscure the details very long term to protect customers who might not have installed the fix. "That's security by obscurity." But that's still the same thing, just smaller: IF they knew about it, then they could exploit it. It's just a matter of degree. Similarly, OCO makes it harder to find the way around, say, a CPUID or license key. But protecting passwords is a valid use of "That's security by obscurity." A password is not a pervasive defect as those other cases are. "protecting passwords" in what context? I'm sure your point is valid but it's escaping me! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@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)?
Paul Gilmartin wrote: >I believe otherwise. I know of a case where a vendor allowed a product >to escape to the field containing a tester's back door, and another >related to II14489. Either could be exploited with no brute force, >merely knowledge of the existence and nature of the defect. In the >case of the latter, the vendor chose to obscure the details very long >term to protect customers who might not have installed the fix. >"That's security by obscurity." But that's still the same thing, just smaller: IF they knew about it, then they could exploit it. It's just a matter of degree. Similarly, OCO makes it harder to find the way around, say, a CPUID or license key. >But protecting passwords is a valid use of "That's security by >obscurity." A password is not a pervasive defect as those other cases >are. "protecting passwords" in what context? I'm sure your point is valid but it's escaping me! -- 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 Tue, 16 Jan 2024 12:31:36 -0500, Phil Smith III wrote: >... >For example, 256-bit AES can be broken by brute force-if you have until the >end of time. (And if you'll know it when you see it, another issue.) But that >"until the end of time" means you can use it to outrun the bear. > >When people say "That's security by obscurity", they really mean "That's weak >security because the barriers aren't high enough". That's all. It's not a big >revelation. > I believe otherwise. I know of a case where a vendor allowed a product to escape to the field containing a tester's back door, and another related to II14489. Either could be exploited with no brute force, merely knowledge of the existence and nature of the defect. In the case of the latter, the vendor chose to obscure the details very long term to protect customers who might not have installed the fix. "That's security by obscurity." But protecting passwords is a valid use of "That's security by obscurity." A password is not a pervasive defect as those other cases are. -- 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)?
Leonard D Woren wrote, in part: >Software can be hacked. Um. And? What's your point? Anything can be hacked: https://xkcd.com/538/ The phrase "security by obscurity" has bothered me for years. It's *ALL* security by obscurity. If you have enough "stuff"-time, money, guns (wrenches)-you can get in. The trick is to make it hard enough that you outrun the bear. For example, 256-bit AES can be broken by brute force-if you have until the end of time. (And if you'll know it when you see it, another issue.) But that "until the end of time" means you can use it to outrun the bear. When people say "That's security by obscurity", they really mean "That's weak security because the barriers aren't high enough". That's all. It's not a big revelation. .phsiii -- 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)?
Radoslaw Skorupka wrote > Note: Dataset Encryption (DSE) is *not* a replacement for RACF or other > security system. > It is a solution to keep data secret even if you have (unintended) access to > the dataset. Bad RACF authority? NO! > It could be administrative access via STGADMIN, shared DASD, etc. I think z/OS data set encryption is a solution for protecting z/OS data when it is accessed outside of its normal environment. That could be via specialised authorised programs (such as ADRDSSU), via other systems (when a volume is accessed by a z/OS system using a different RACF database), where a volume is accessed by another operating system (such as z/VM or Linux), where a data set backup is transported to another system entirely, or any other situation where the data is not under its normal RACF controls. Lennie Dymoke-Bradshaw https: //rsclweb.com -- 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)?
W dniu 16.01.2024 o 03:13, Michael Stein pisze: On Mon, Jan 15, 2024 at 02:41:45PM -0600, Walt Farrell wrote: On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman wrote: For encryption, the analogous method might be: Once a jobstep has Opened an encrypted data set to read it, they cannot write to, nor Open, an unencrypted output data set. You just mark the jobstep, and have a bit in the DEB indicating encryption, and for a marked jobstep you don't allow a write to a DEB that doesn't have the bit set. So I could write the secret decrypted data out to an encrypted dataset which had a different encryption key -- one which I had easier access to? Security is hard, especially read security. Yes, you can have open for input and/or output many datasets. Any of them may be unencrypted, encrypted with key A, or key B, C, etc. You can copy data between those datasets. Assumption: 1. you are authorized to each of the datasets in DATASET class. 2. You have READ access to key A, B, C, etc. Note: Dataset Encryption (DSE) is *not* a replacement for RACF or other security system. It is a solution to keep data secret even if you have (unintended) access to the dataset. Bad RACF authority? NO! It could be administrative access via STGADMIN, shared DASD, etc. -- Radoslaw Skorupka Lodz, Poland -- 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 think you underestimate the difficulty in "hacking" the software and that "single spit" of data is much more protected than you let on. As for an IBMer "admitt[ing] that [you were] correct," I strongly suspect that you read WAY more into such a statement than was actually there. Your PS wasn't terribly worrisome either. Of course someone knows all the key part holders to be able to bring them in. That's standard security practice. The risk isn't that someone knows the people. The risk is of collusion. If you have 3 key parts, you need 3 different people to all agree to act nefariously. Eric Rossman -Original Message- From: IBM Mainframe Discussion List On Behalf Of Leonard D Woren Sent: Monday, January 15, 2024 9:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? OK. So we've established that the key is set via software. Software can be hacked. And now there's only a single spit of data to focus all the effort on. Years ago at a SHARE presentation, I caught an IBMer after the session and they admitted that I was correct. /Leonard P.S. Someone has to know all the security officers in order to contact them when necessary to input the keys. -- 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)?
OK. So we've established that the key is set via software. Software can be hacked. And now there's only a single spit of data to focus all the effort on. Years ago at a SHARE presentation, I caught an IBMer after the session and they admitted that I was correct. /Leonard P.S. Someone has to know all the security officers in order to contact them when necessary to input the keys. Radoslaw Skorupka wrote on 1/15/2024 6:44 AM: It is being done everytime you buy new machine and use ICSF. TKE can be used for that, but even without it is feasible and secure. ...and secure. :-) 1. Master key is divided into parts. How many? 2 or more. 2. Each part is know to only one security officer. Note, the officers need not to know each other. That's information security - no single person can disclose the key. No one knows the key. 3. Every officer is "duplicated" by another person. That's data security - lost key part is not a problem, because we have another copy of the part. So, let's assuming 2 key parts and three copies we have 6 persons and 6 safes to keep the parts. -- 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 Mon, Jan 15, 2024 at 02:41:45PM -0600, Walt Farrell wrote: > On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman > wrote: > For encryption, the analogous method might be: Once a jobstep has > Opened an encrypted data set to read it, they cannot write to, nor Open, > an unencrypted output data set. You just mark the jobstep, and have a > bit in the DEB indicating encryption, and for a marked jobstep you don't > allow a write to a DEB that doesn't have the bit set. So I could write the secret decrypted data out to an encrypted dataset which had a different encryption key -- one which I had easier access to? Security is hard, especially read security. -- 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)?
In CICS one can have encrypted and non-encrypted files open simultaneously. This is kind of a MUAS, Multiple User Address Space. I was going to mention the problem of Connect:Direct but let it go. But since the CICS thing was also brought up C:D has similar issues to CICS where it can be a stand-alone or multiple address spaces working in conjunction with each other. Think CICS-Plex, or C:D-Plex. CICS can have Terminal owning, File owning, Application owning address spaces (REgions). And can share data between them. Steve Thompson On 1/15/2024 4:08 PM, Walt Farrell wrote: On Mon, 15 Jan 2024 14:45:06 -0600, Joe Monk wrote: How would that be practical? How would you, for instance, do a batch update to an encrypted dataset from a CICS vsam file? Sorry; I don't understand the question. How do you do it today? -- 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 Mon, 15 Jan 2024 14:45:06 -0600, Joe Monk wrote: >How would that be practical? How would you, for instance, do a batch update >to an encrypted dataset from a CICS vsam file? Sorry; I don't understand the question. How do you do it today? -- Walt -- 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)?
How would that be practical? How would you, for instance, do a batch update to an encrypted dataset from a CICS vsam file? Joe On Mon, Jan 15, 2024 at 2:42 PM Walt Farrell wrote: > On Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman > wrote: > > >Answering a number of comments in order, in one message. > > > >First: I don't think being able to encrypt load libraries is worth it. > Encrypted executables, in general, are not going to increase security. > > > >Jousma, David: > > > >> Additionally, I think IBM dropped the ball a bit in that > >> nothing stops a permitted user to copy that data to an > >> un-encrypted dataset. > > > >Another topic we discussed. Here's the rub: How would you > >implement that? What would prevent one application from opening > >a data set and reading, then closing it and opening a new data > >set to write out. How would IBM detect that? I get that we could > >have prevented it for IDCAMS REPRO or similar programs but it > >would impossible to do it reliably for all possible programs. > > > > RACF did something you could consider as a model, with EXECUTE access to > programs. Once a user has loaded a program that they only have EXECUTE > authority for (not READ), they cannot load another program that is not > Program Controlled. (There's a bit more to it, but that's sufficient for > this discussion, I think.) > > For encryption, the analogous method might be: Once a jobstep has Opened > an encrypted data set to read it, they cannot write to, nor Open, an > unencrypted output data set. You just mark the jobstep, and have a bit in > the DEB indicating encryption, and for a marked jobstep you don't allow a > write to a DEB that doesn't have the bit set. > > I can't say whether that would solve any real problems, but if there's a > concern about someone reading an encrypted file and writing it unencrypted, > that could solve part of it. The next layer, though, might be wanting to > protect against them sending it over the network, and being sure how it's > treated at the other end if they do. > > -- > Walt (former lead RACF designer/architect for that function) > > -- > 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 Mon, 15 Jan 2024 16:15:38 +, Eric D Rossman wrote: >Answering a number of comments in order, in one message. > >First: I don't think being able to encrypt load libraries is worth it. >Encrypted executables, in general, are not going to increase security. > >Jousma, David: > >> Additionally, I think IBM dropped the ball a bit in that >> nothing stops a permitted user to copy that data to an >> un-encrypted dataset. > >Another topic we discussed. Here's the rub: How would you >implement that? What would prevent one application from opening >a data set and reading, then closing it and opening a new data >set to write out. How would IBM detect that? I get that we could >have prevented it for IDCAMS REPRO or similar programs but it >would impossible to do it reliably for all possible programs. > RACF did something you could consider as a model, with EXECUTE access to programs. Once a user has loaded a program that they only have EXECUTE authority for (not READ), they cannot load another program that is not Program Controlled. (There's a bit more to it, but that's sufficient for this discussion, I think.) For encryption, the analogous method might be: Once a jobstep has Opened an encrypted data set to read it, they cannot write to, nor Open, an unencrypted output data set. You just mark the jobstep, and have a bit in the DEB indicating encryption, and for a marked jobstep you don't allow a write to a DEB that doesn't have the bit set. I can't say whether that would solve any real problems, but if there's a concern about someone reading an encrypted file and writing it unencrypted, that could solve part of it. The next layer, though, might be wanting to protect against them sending it over the network, and being sure how it's treated at the other end if they do. -- Walt (former lead RACF designer/architect for that function) -- 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)?
Answering a number of comments in order, in one message. First: I don't think being able to encrypt load libraries is worth it. Encrypted executables, in general, are not going to increase security. Jousma, David: > Encrypt everything with the same HLQ, with the same key > that's a big exposure if the key gets accidentally deleted. > Not sure what the rule of thumb is either, as one key per > dataset turns into a key management nightmare. We had a number of long discussions about this topic and we ended up deciding that there isn't a one-size-fits-all answer, so my guidance would be to do what makes sense in your environment. Whenever I speak on this, I always say that one key for all data sets is too few (as is zero), but so is one key per data set (unless you have a really unusual environment. In general, one key for data sets containing "related data" (however you defined that in your environment) is usually a good guideline. > Additionally, I think IBM dropped the ball a bit in that > nothing stops a permitted user to copy that data to an > un-encrypted dataset. Another topic we discussed. Here's the rub: How would you implement that? What would prevent one application from opening a data set and reading, then closing it and opening a new data set to write out. How would IBM detect that? I get that we could have prevented it for IDCAMS REPRO or similar programs but it would impossible to do it reliably for all possible programs. > The technology that I see as beneficial is one that I think > is in the works with ibm in that data will never be decrypted > including during execution. I forget the term used for that. Homomorphic encryption. Phil Smith III: > If the rational is "Encryption is good because encryption", > that's dangerous, because you're not really protecting very > much. Right. I've been in crypto for a pretty long time and this is the kind of message I keep trying to share. While I want everyone to use cryptography, I want them to use for the right reasons, and not just for everything in the world. I had an issue with the "Everything is encrypted" mantra we had for one of our sales pitches for a previous z model. I get the reason behind it but it set the wrong picture in executives' heads. Rick Troth: > Many people use encryption like it was fairy dust: just > sprinkle it liberally and everything is safer. I love your description. Cryptography, when used properly and consistently, does make things safer, but as you said, the emphasis is on both properly AND consistently. > FPE is brilliant. But like everything else, it's not a be-all > and end-all. Agreed. FPE solves a specific problem and does a great job of it, just like data set encryption. Radoslaw Skorupka: > STGADMIN profiles mitigate the problem, but there is also DASD > access from another LPAR and another security rules. This, to me, is the main reason behind data set encryption. The folks who have authority to the key (and the data set) have access to the data. Those who only have access to the key or to the raw encrypted data have nothing. -- 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)?
W dniu 15.01.2024 o 05:16, Phil Smith III pisze: Steve Estle wrote, in part: but we'd like to encrypt as much as possible in our environment Why? What problem are you trying to solve? Remember that DSE provides protection against exactly two attacks: 1) Someone getting at the wire between the array and the CEC For that purpose IBM implemented FICON channel encryption. Whole transmission can be encrypted, whether it is business data or just ICKDSF command. 2) Rogue storage admin IMHO that's one of the most important reasons. STGADMIN profiles mitigate the problem, but there is also DASD access from another LPAR and another security rules. -- Radoslaw Skorupka Lodz, Poland -- 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 being done everytime you buy new machine and use ICSF. TKE can be used for that, but even without it is feasible and secure. ...and secure. :-) 1. Master key is divided into parts. How many? 2 or more. 2. Each part is know to only one security officer. Note, the officers need not to know each other. That's information security - no single person can disclose the key. No one knows the key. 3. Every officer is "duplicated" by another person. That's data security - lost key part is not a problem, because we have another copy of the part. So, let's assuming 2 key parts and three copies we have 6 persons and 6 safes to keep the parts. -- Radoslaw Skorupka Lodz, Poland W dniu 15.01.2024 o 02:52, Leonard D Woren pisze: There has to be a way to set it via software. What happens when you replace the machine including the hardware where the master key is stored? How is the key set into the disaster recovery machine? /Leonard Jousma, David wrote on 1/14/2024 4:50 PM: Pretty hard to mess up the master key, since it only lives in the crypto hardware. That's the other thing though. Sounds like the OP wants to encrypt everything with the same HLQ, with the same key that's a big exposure if the key gets accidentally deleted. Not sure what the rule of thumb is either, as one key per dataset turns into a key management nightmare. Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Leonard D Woren Sent: Sunday, January 14, 2024 7:05:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? (I read the whole thread before starting this reply. ) Steve Estle wrote on 1/13/2024 8: 28 AM: > [. . . ] > My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [. . . ] > (I read the whole thread before starting this reply.) Steve Estle wrote on 1/13/2024 8:28 AM: [...] My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [...] 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. So, you have poor naming conventions and a poor security system, and you want IBM to make difficult changes which will potentially affect all customers negatively? 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? I'd vote the highest value of "no". An aside, since I didn't keep track of which comment mentioned this (maybe it was on an old item cross-posted from RACF-L?). For those concerned about ransomware, z/OS encryption of all data at rest means that a ransomware hacker need only mess up the master key so that no data sets can be decrypted. No need to waste time encrypting all data, since it's already encrypted. /Leonard -- 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. Keys are data. IEFBR14 code is datum. However there are different needs and requirements for data. Auditor always asked me about financial (application) data security. Never about programs. Of course one would like to have everything SECURE. Encryption is on of means. What to encrypt? EVERYTHING. Is it possible? No. It is possible to encrypt some kinds of data. For other the encryption can be impossible, too complex or just too expensive in terms of performance. Would I like to have encrypted programs? Actually I don't care. IMHO the pervasive encryption provide little advantage when used in properly secured (with RACF) environment. I mean business data. However I understand requirements and implement it everywhere when ordered. BTW: One of datasets where encryption provide real value is RACF db. Yes, it should be protected. However I have seen many shops (as external consultant) where I was able to copy it or even overwrite. Not to forget about backup copies. With encryption the stolen copy is just unusable. Of course KDFAES makes it much less usable than previously. -- Radoslaw Skorupka Lodz, Poland W dniu 14.01.2024 o 00:40, Seymour J Metz pisze: 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
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
While I strongly believe there is a technical reason behind, it is NOT the one described below. Both PDSE and basic PS can be encrypted. The requirement: SMS-managed. -- Radoslaw Skorupka Lodz, Poland W dniu 14.01.2024 o 06:50, Attila Fogarasi pisze: 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
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
It might be difficult to satisfy timing constraints using TCP/IP to connect Hercules to some real hardware. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Rick Troth Sent: Monday, January 15, 2024 8:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? On 1/13/24 11:28, Steve Estle wrote: > I know this seems innocuous, but we'd like to encrypt as much as possible in > our environment ... Forgive my tone, Steve. And please don't take this as directed at you, but at the broader industry, especially at "seatback magazine management". Many people use encryption like it was fairy dust: just sprinkle it liberally and everything is safer. That's not true, and the reasons are not immediately obvious. But the problem starts with the requirement to /decrypt/ before data can actually be used. And if *everything* is encrypted then there are more cases where things are getting decrypted. I've been using encryption, both professionally and personally, for more than three decades, and I find that I'm getting increasingly selective day by day. I feel your pain about certain data sets being difficult. And don't get me started about seed keys needed for whole disk situations. -- R; <>< -- 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 1/14/24 01:07, Phil Smith III wrote: aul 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. FPE is brilliant. But like everything else, it's not a be-all and end-all. Phil nails it: not so great for binary blobs. I *strongly* recommend FPE for the most sensitive information when it's in a structured form. (Such as credit card numbers coming from the reader to the POS terminal.) The value of FPE is that you can actually *use* the info WHILE IT IS ENCRYPTED. This is available *now* and is significantly easier than homomorphic encryption. More vendors should offer FPE. The best we get from most vendors is tokenization, but that doesn't scale well. -- R; <>< -- 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:28, Steve Estle wrote: I know this seems innocuous, but we'd like to encrypt as much as possible in our environment ... Forgive my tone, Steve. And please don't take this as directed at you, but at the broader industry, especially at "seatback magazine management". Many people use encryption like it was fairy dust: just sprinkle it liberally and everything is safer. That's not true, and the reasons are not immediately obvious. But the problem starts with the requirement to /decrypt/ before data can actually be used. And if *everything* is encrypted then there are more cases where things are getting decrypted. I've been using encryption, both professionally and personally, for more than three decades, and I find that I'm getting increasingly selective day by day. I feel your pain about certain data sets being difficult. And don't get me started about seed keys needed for whole disk situations. -- R; <>< -- 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 can be set via software but can be disabled by control points. There are RACF controls on the Crypto services that are needed. There are controls that can used to stop one domain setting the key for another. More serious users will have TKE workstations with card readers and multiple key holders. Leonard is correct that it is a single point of attack. But it is a very well-protected point of attack. Also note that the multiple card holders can re-create the master keys. Lennie Dymoke-Bradshaw https: //rsclweb.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Leonard D Woren Sent: 15 January 2024 01:53 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? There has to be a way to set it via software. What happens when you replace the machine including the hardware where the master key is stored? How is the key set into the disaster recovery machine? /Leonard Jousma, David wrote on 1/14/2024 4:50 PM: > Pretty hard to mess up the master key, since it only lives in the crypto > hardware. > > That's the other thing though. Sounds like the OP wants to encrypt > everything with the same HLQ, with the same key that's a big exposure if > the key gets accidentally deleted. Not sure what the rule of thumb is > either, as one key per dataset turns into a key management nightmare. > > Dave Jousma > > Vice President | Director, Technology Engineering > > > Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand > Rapids, MI 49546 > > 616.653.8429 > > From: IBM Mainframe Discussion List on > behalf of Leonard D Woren > Sent: Sunday, January 14, 2024 7:05:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE > format)? > > (I read the whole thread before starting this reply. ) Steve Estle > wrote on 1/13/2024 8: 28 AM: > [. . . ] > My true reason for composing > this is that we've discovered the inability to encrypt load libraries > - even in PDSE format. [. . . ] > > > > (I read the whole thread before starting this reply.) > > Steve Estle wrote on 1/13/2024 8:28 AM: >> [...] >> My true reason for composing this is that we've discovered the inability to >> encrypt load libraries - even in PDSE format. > [...] >> 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. > So, you have poor naming conventions and a poor security system, and > you want IBM to make difficult changes which will potentially affect > all customers negatively? > >> 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? > I'd vote the highest value of "no". > > > An aside, since I didn't keep track of which comment mentioned this > (maybe it was on an old item cross-posted from RACF-L?). For those > concerned about ransomware, z/OS encryption of all data at rest means > that a ransomware hacker need only mess up the master key so that no > data sets can be decrypted. No need to waste time encrypting all > data, since it's already encrypted. > > > /Leonard > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > This e-mail transmission contains information that is confidential and may be > privileged. It is intended only for the addressee(s) named above. If you > receive this e-mail in error, please do not read, copy or disseminate it in > any manner. If you are not the intended recipient, any disclosure, copying, > distribution or use of the contents of this information is prohibited. Please > reply to the message immediately by informing the sender that the message was > misdirected. After replying, please erase it from your computer system. Your > assistance in correcting this error is appreciated. > > -- > For IBM-MAIN subscribe / signoff / archive
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
Steve Estle wrote, in part: >but we'd like to encrypt as much as possible in our environment Why? What problem are you trying to solve? Remember that DSE provides protection against exactly two attacks: 1) Someone getting at the wire between the array and the CEC 2) Rogue storage admin Those are the risks for which it was designed and implemented, and it does a fine job of those. Otherwise, it's no different from RACF/ACF2/TSS protecting stuff in the first place. (I'm assuming you have encrypting DASD already.) If the rational is "Encryption is good because encryption", that's dangerous, because you're not really protecting very much. I realize that this may be management's delusion, but it's not good. There's way too much of that out there-"We protected something, yay, now we're safe(r)". Not necessarily. -- 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/14/2024 5:52 PM, Leonard D Woren wrote: There has to be a way to set it via software. What happens when you replace the machine including the hardware where the master key is stored? How is the key set into the disaster recovery machine? In our case, we brought z/OS up on the DR machine and then MK from the ICSF panels in ISPF. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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 has to be a way to set it via software. What happens when you replace the machine including the hardware where the master key is stored? How is the key set into the disaster recovery machine? /Leonard Jousma, David wrote on 1/14/2024 4:50 PM: Pretty hard to mess up the master key, since it only lives in the crypto hardware. That's the other thing though. Sounds like the OP wants to encrypt everything with the same HLQ, with the same key that's a big exposure if the key gets accidentally deleted. Not sure what the rule of thumb is either, as one key per dataset turns into a key management nightmare. Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Leonard D Woren Sent: Sunday, January 14, 2024 7:05:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? (I read the whole thread before starting this reply. ) Steve Estle wrote on 1/13/2024 8: 28 AM: > [. . . ] > My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [. . . ] > (I read the whole thread before starting this reply.) Steve Estle wrote on 1/13/2024 8:28 AM: [...] My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [...] 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. So, you have poor naming conventions and a poor security system, and you want IBM to make difficult changes which will potentially affect all customers negatively? 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? I'd vote the highest value of "no". An aside, since I didn't keep track of which comment mentioned this (maybe it was on an old item cross-posted from RACF-L?). For those concerned about ransomware, z/OS encryption of all data at rest means that a ransomware hacker need only mess up the master key so that no data sets can be decrypted. No need to waste time encrypting all data, since it's already encrypted. /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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)?
Pretty hard to mess up the master key, since it only lives in the crypto hardware. That's the other thing though. Sounds like the OP wants to encrypt everything with the same HLQ, with the same key that's a big exposure if the key gets accidentally deleted. Not sure what the rule of thumb is either, as one key per dataset turns into a key management nightmare. Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Leonard D Woren Sent: Sunday, January 14, 2024 7:05:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? (I read the whole thread before starting this reply. ) Steve Estle wrote on 1/13/2024 8: 28 AM: > [. . . ] > My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [. . . ] > (I read the whole thread before starting this reply.) Steve Estle wrote on 1/13/2024 8:28 AM: > [...] > My true reason for composing this is that we've discovered the inability to > encrypt load libraries - even in PDSE format. [...] > 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. So, you have poor naming conventions and a poor security system, and you want IBM to make difficult changes which will potentially affect all customers negatively? > 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? I'd vote the highest value of "no". An aside, since I didn't keep track of which comment mentioned this (maybe it was on an old item cross-posted from RACF-L?). For those concerned about ransomware, z/OS encryption of all data at rest means that a ransomware hacker need only mess up the master key so that no data sets can be decrypted. No need to waste time encrypting all data, since it's already encrypted. /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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 read the whole thread before starting this reply.) Steve Estle wrote on 1/13/2024 8:28 AM: [...] My true reason for composing this is that we've discovered the inability to encrypt load libraries - even in PDSE format. [...] 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. So, you have poor naming conventions and a poor security system, and you want IBM to make difficult changes which will potentially affect all customers negatively? 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? I'd vote the highest value of "no". An aside, since I didn't keep track of which comment mentioned this (maybe it was on an old item cross-posted from RACF-L?). For those concerned about ransomware, z/OS encryption of all data at rest means that a ransomware hacker need only mess up the master key so that no data sets can be decrypted. No need to waste time encrypting all data, since it's already encrypted. /Leonard -- 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've been reading this thread and the question I have is what problem are we (or you) trying to solve, or prevent? Making auditors happy who may not understand how a system functions? Trying to prevent a bad actor(s) from making the system unusable (ransomware attack?)? If we start with the IPL, how could it be encrypted and load? A bit of a problem. So if we process the IPL, and the libraries that the O/S will be loaded from and check them via a check sum. If the HMC fails this Now if we pickup the LPA as it had been from the prior IPL, we would need to know its check sums and run that again. (Shades of FIPS). But if we do a CLPA, we now have to verify every program going into LPA. So how would we checksum the whole system so we can know if it has been tampered with? Eventually we will get to "modified" code from "user" libraries. If we cause those to go through check sums we might be able to detect something wrong. But encryption of all the programs leaves us in a bad spot if someone gets a script into the system and encrypts things for us, a malware attack kind of thing. So just what is it that we are trying to stop and detect and at what point will we have to have a PROGRAM environment "set-aside" that we run from so that we avoid such a problem with programs (otherwise ones and zeros making programs data to something :) ). I've recently had a class on the process out of the HMC and I've forgotten the tech name for it but a "signed" IPL as it were. That got me to thinking about other issues, and so here we are with an IBM Main discussion on this very issue/topic. Steve Thompson On 1/14/2024 1:09 AM, ITschak Mugzach wrote: 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
Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
The technical reason "why" is because it would be very difficult to do, would have adverse performance effects for the system, and there is not at this point a business case for providing it. So you're not going to get it just because you think it sounds nice (and even because it sounds "logical" to have it be part of the whole encryption ballgame). It would need to provide real business value. Please keep in mind that encryption is not about verification. It is about hiding. Program signing is about verification. Program signing is available for PDSE load libraries (not file system directories) and some level of program signing is now available for PDS load libraries to accommodate the needs of Validated Boot for z/OS). FWIW, the validation of a program signature has an unavoidable adverse performance cost too. For some situations, that cost is worthwhile (ICSF has a hard requirement in this area). If you have a business need for program signature of file system directories (more than a "it would be very nice if"), then by all means make your needs known. It might well not happen without your input. 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: Technical Reason? - Why you can't encrypt load libraries (PDSE format)?
On 1/14/2024 7:05 AM, Jousma, David wrote: The technology that I see as beneficial is one that I think is in the works with ibm in that data will never be decrypted including during execution. I forget the term used for that. Homomorphic encryption, but that has limited use. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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)?
We looked at dataset encryption to please our auditors.Just trying to see the benefit, honestly.If you are a permitted user of the dataset by any means, then you have to be permitted to the encryption key profile as well. So who are you protecting the data from? Storage managers? Storage managers don't need access to datasets to manage them. Additionally, I think IBM dropped the ball a bit in that nothing stops a permitted user to copy that data to an un-encrypted dataset. IMO, once encrypted any copies inherit the same encryption. The technology that I see as beneficial is one that I think is in the works with ibm in that data will never be decrypted including during execution. I forget the term used for that. Other parts of PE we are doing, focusing mostly on encrypted IP connections, encrypted ficon, and possibly encrypted cf structures. Dave Jousma Vice President | Director, Technology Engineering Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 From: IBM Mainframe Discussion List on behalf of Steve Estle Sent: Saturday, January 13, 2024 11:28:58 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 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 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- 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)?
Get your mind out of my gutter! -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Jay Maynard Sent: Sunday, January 14, 2024 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Technical Reason? - Why you can't encrypt load libraries (PDSE format)? John von Neumann, call your office. On Sat, Jan 13, 2024 at 5:41 PM Seymour J Metz wrote: > 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 > -- Jay Maynard -- 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)?
John von Neumann, call your office. On Sat, Jan 13, 2024 at 5:41 PM Seymour J Metz wrote: > 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 > -- Jay Maynard -- 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/2024 9:50 PM, Attila Fogarasi wrote: 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). AES256 encryption is supported for basic, large, and extended format data sets as well as PDSE. I suppose whether such encryption is considered "pervasive" or not depends on how much of your mainframe's data overall is encrypted this way. Program object libraries (the subject of this thread) are the exception. Seymour's conjecture seems reasonable, but I always assumed it was because most LOADs come from shared libraries you never OPEN (e.g., LNKLST). If such libraries were encrypted, the keylabels would need to be saved, CSF services would need to be invoked, SAF calls would need to be issued against the appropriate keylabel resources in the CSFKEYS class, and every user in the shop would need SAF READ access to those resources. A lot of extra work/overhead for quite literally zero gain... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- 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 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, >
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: 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
