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 <walt.farr...@gmail.com> wrote: > On Mon, 15 Jan 2024 16:15:38 +0000, Eric D Rossman <edros...@us.ibm.com> > 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
