Re: Instream Commands
Thanks. Walt -- Walter Farrell/Poughkeepsie/i...@ibmus STSM, z/OS Security Design 845-435-7750 (tie: 295) e-mail: wfarr...@us.ibm.com From: Shmuel (Seymour J.) Metz shmuel+ibm-m...@patriot.net To: Walter Farrell/Poughkeepsie/i...@ibmus Date: 11/14/2009 10:45 PM Subject: Re: Instream Commands In listserv%200910140909312853.0...@bama.ua.edu, on 10/14/2009 at 09:09 AM, Walt Farrell wfarr...@us.ibm.com said: Offline due to age. Commands contained within a job's JCL should run as though issued by the execution user ID (not necessarily the same as the submitting user ID). The OP asked If that is the case, under whose address space and userid does it run. Just in case this question comes up again, it runs in the Converter address space. You are correct, of course, about the security environment, which is for the job owner rather than the Converter, JES or submitter. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RACF Research: ICHAUTAB
(If you don't use RACF, feel free to ignore this message.) In z/OS R10 we implemented some new RACF checks in the Health Checker for z/OS to warn you if you have any entries in ICHAUTAB, the RACF Authorized Caller Table. For those not familiar with ICHAUTAB, it's a very old RACF facility that you can use to allow non-authorized (neither APF, supervisor state, nor system key) programs to issue some forms of RACROUTE REQUEST=VERIFY and RACROUTE REQUEST=LIST. However, as we document it's dangerous to use ICHAUTAB, and we recommend not using it, so we decided that we should implement the check for entries in ICHAUTAB and warn you about them. Ideally, I would like to completely remove ICHAUTAB processing from RACF, and simply require that all invokers of the RACROUTE REQUEST=VERIFY and LIST functions run with authorization (APF, supervisor state, or system key). So I thought I'd conduct a bit of research to see who, if anyone, is using it and why. This should help us gauge the consequences of removing ICHAUTAB, should we decide to do so in some future z/OS release. So, if you use RACF and have any entries in ICHAUTAB, I'd like you to send me an email describing the entries that you have and why you need them. Please send the responses to me ( mailto: [EMAIL PROTECTED] ), not to IBM-MAIN. Depending on the responses I may make further requests or provide some feedback to the list. I've also posted this on RACF-L. Apologies in advance to those of you on both lists who will see this twice, and to those of you on IBM-MAIN who do not use RACF. Thanks, Walt -- Walter Farrell/Poughkeepsie/[EMAIL PROTECTED] STSM, z/OS Security Design 845-435-7750 (tie: 295) e-mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Lnnnnn tapes mystery
On 4/25/2007 8:24 AM, Paul Gilmartin wrote: Is it sufficient explanation that storage used to be expensive? But why does the deficiency persist into the 21st century? Perhaps because it's difficult to change standards and get everyone to recode their applications, especially across different types of systems? Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TSO logon exits
On 4/18/2007 8:37 AM, Mark Zelden wrote: Too bad WHEN(SYSID()) is only valid for the program class. Wonder why. The usual reasons, basically. At the time we developed WHEN(SYSID...) we had an urgent requirement for it for the PROGRAM class. Implementing the more general solution would have cost us more in resources (people) than we had available just then, given the other items we needed to do, so we implemented only the more limited solution. Feel free to submit a requirement. In the meantime, using separate proclibs for the different systems is probably the simplest solution, though I sometimes suggest a different method that requires a small bit of programming but simplifies maintenance of the logon procs by keeping just one copy of them: (a) write an APF-authorized, non-LPA program. (b) that program will simply XCTL to IKJEFT01, passing the original registers. Then change the logon procs to run that new program rather than IKJEFT01, and use PROGRAM control for the new program, with WHEN(SYSID...). If you have the case of some procs that should be usable on any system, you can leave them directly executing IKJEFT01. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF and Member Level Protection
On 4/9/2007 1:25 PM, Edward Jaffe wrote: Paul Gilmartin wrote: Since BPAM now supports read access to HFS directories (barring those utilities that balk at this), might an alternative be to use HFS rather than PDS, and protect the members with ACLs? If so, it's a solved problem. What about write access? That gets back to the question about what one really means by member protection, I think. Many times when I've heard the question it really has meant a desire to control who can update which members. If all the readers of the PDS support the simulation of a PDS by a UNIX directory, then you could (perhaps) simply tell all the updaters that they needed to update UNIX files rather than updating a PDS directory. I can envision a lot of cases that would not handle, of course. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF and Member Level Protection
On 4/4/2007 3:33 PM, Steven Conway wrote: CA Top Secret supports member level security in a PDS or PDSE, allowing a variance of access authority to users of the dataset versus an individual member. We have that plugged in. A few months ago, there was a problem that led me to open an issue with Top Secret to verify what they do, and with another vendor to determine why their program hung on failed access at the member level. The other vendor runs RACF, and today told me his RACF Admin says RACF does not support member level protection. Not being a RACF guy, I went to the books. Neither the Admin Guide or User's Guide yielded anything to searches on 'member protection' or 'member level protection'. I would have sworn all three major security packages supported this function, but I can't find anything to verify that. Will someone who knows the true scoop hook me up with either No, RACF doesn't do that or Hey, dope. Look at reference here. It is more appropriate to say that z/OS does not support member level protection. As the resource manager for data sets, it would be up to DFP or DFSMS to call the security product to make security checks for members, and DFP/DFSMS does not do so. Any security product that provides such protection has therefore had to modify z/OS in some way in order to do so. RACF does not make such modifications to other components of z/OS. If you would like member level protection supported natively in z/OS, please submit a requirement via SHARE or directly via someone on your IBM account team, and ask DFSMS for that support. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ishell vs 3.17
On 3/23/2007 3:33 PM, Bryan Klimek wrote: Now that we have our first LPAR up and running on z/OS 1.8, I see that ISPF option 3.17 is available. 17 Udlist Print or display (to process) z/OS UNIX directory list This utility seems to have most all of the capabilities that the ISHELL has. I tried to search for a techdoc or redbook that would explain the history of why 3.17 Udlist was created and how it compares to ISHELL. Which direction is IBM headed? Are ISHELL's days numbered? Will IBM continue to support and enhance both interfaces. I don't know of an official answer, and we have not made any statements of direction about that officially as far as I know, but I'm told it seems likely that we'll stop accepting requirements for enhancements to the ishell file/directory functions and to oedit/obrowse. Instead we'll depend on ISPF for enhancements in that area. However, ishell also has other functions that ISPF has not picked up. so ishell may provide enhancements in those areas in the future. By the way, I generally suggest posting z/OS UNIX questions to the MVS-OE mailing list rather than IBM-MAIN, as it's more likely to reach IBM's z/OS UNIX developers over there. However, this question overlaps both UNIX and ISPF, so it's hard to say which is the better list. Or whether ISPF-L would be a good one, too. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
On 2/15/2007 7:59 PM, Don Leahy wrote: It is pretty obvious that weak passwords greatly increase the likelihood that a brute force attack will work. However, since most (all?) systems revoke userids after a very small number of unsuccessful password attempts, the issue of strong vs weak passwords is totally irrelevant to your end users, so why burden them with strict password policies? Even a weak password will stand up to a brute force attack if the userid is revoked after 3 failures. Protecting the password data base from theft is the security administrator's job, not the end user's. It doesn't matter how strong the safe or how complex the combination, if the thief can tuck it under his arm and take it home with him to work on at his leisure. Good points. Note, however, that there's a difference between requiring mixed-case passwords and having overly strict password rules. A rule requiring 8-character passwords, with at least one upper case alpha, one lower case alpha, and one numeric is not overly strict, and can be met easily by the users. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
On 2/13/2007 1:49 PM, [EMAIL PROTECTED] wrote: I believe that allowing mixed-case does increase security, as it makes the number of possible passwords of any given length much greater, and increases the amount of time needed for brute-force password guessing. How can you do a brute-force password guess when you have a max of 3 password attempts before the ID is revoked? Or are you saying that mixed-case increases security in those rare shops that haven't implemented revoking IDs on wrong passwords? Revocation based on number of invalid attempts should (for the most part) prevent attacks from people actually trying to login. It does not stop attacks from people who have acquired a copy of your database, and can thus see the encrypted data in the password fields. Given the encrypted authentication data, and the user ID, the brute force attack would involve examining all possible passwords until you find one that generates that same encrypted data. With mixed-case that brute force process needs to cover more possible passwords, and thus will take longer, on average. You have a possible password space (for 8-character passwords) of 65**8 rather than 39**8. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
On 2/13/2007 12:30 PM, Hal Merritt wrote: Other than there is not one shred of evidence to suggest this makes for stronger security? And ample experiences of increased help desk calls that actually lead to weakened security? And complex passwords generate sticky notes? Mixed-case does not necessarily mean the password will seem more complex to the user. That kind of complexity is really a function of the rules that the security administrator tries to impose. If you tell me I can use mixed-case, but do not restrict where I put the characters, then I can, for example, use two words with initial or trailing caps, and other letters lower-case. That is then more complex for a brute-force password cracker, but no more complex for me as a user. Only auditors think that this adds value. Those with actual knowledge think otherwise. I believe that allowing mixed-case does increase security, as it makes the number of possible passwords of any given length much greater, and increases the amount of time needed for brute-force password guessing. However, whether you have mixed-case or not, the administrator can compromise security by making the password rules too restrictive. But wait. There is more. Not all applications that actually interact with the keyboard will get this right. Some might pass the password as is, but some may translate it to upper case first. And then there are the character translation issues. The character translation issues should not apply; we're only talking mixed-case A-Z, a-z, not allowing additional characters with variant mappings depending on code page. You're right, though, that all the applications that are passing the password along need to know to leave it as the user entered it. That makes migrating to mixed-case passwords harder than it would have been if we'd made the security product do the upper-casing of the input many years ago. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF Surrogate Authority
On 2/12/2007 10:35 AM, R.S. wrote: Mautalen Juan Guillermo wrote: Itschak: I general i agree with you, but there are some exceptions where surrogate authority proves useful even for users (persons). Example: I needed that 4 users could fully administrate some RACF profile. Basically, they should be able to do what the OWNER of the profile is able to do. However, you know that ownership of profiles only gives administrative authority when the owner is actually a RACF USER and not a RACF GROUP. So, my solution was: I specifically created a user and made it the OWNER of the profile. It is a PROTECTED user. Then, i gave those 4 users authority to submit jobs on behalf of it (surrogate authority). This way, i managed to give those 4 users ownership of the profile. That's why we use group-special. Right. Group-SPECIAL is the intended solution for that, not SURROGAT. SURROGAT will work, but I think it would prove more cumbersome to use (since users would have to submit batch jobs rather than issuing the commands interactively). Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF Surrogate Authority
On 2/12/2007 8:58 AM, R.S. wrote: Jacky Bright wrote: Hi, I have 2 TSO Users (ABC and XYZ) ABC has high level access privileges. XYZ do not have any such access. I am trying to submit 1 job from XYZ userid which require access privileges from ABC. In case I define XYZ user as surrogate user for ABC then is that going to work. what implications it will have at system side ? security issue ? It depends. However surrogate means, XYZ can do everything (*) that ABC can. (*) With exception (AFAIK) to rarely used security labels. SURROGAT can allow many cases of using security labels, too, I believe. Not all cases, though; thanks for mentioning that case as I hadn't thought about it before. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RACF Surrogate Authority
On 2/12/2007 1:27 PM, R.S. wrote: John, it can be more complex: //JOB1 JOB ...USER=ABC .. //STEP1 EXEC PGM=IKJEFT01 .. //SYSTSIN DD * SUMBIT XYZ.USER.PDS(SOMEJOB) Question: who submitted SOMEJOB, ABC submitted the job that's in (SOMEJOB). You will not see anything in the SMF records for (SOMEJOB) related to the user who submitted JOB1. who is execution userid of the job, Whatever it says on the JOB statement in (SOMEJOB), or ABC if it does not have USER=. last but not least: what's inside SOMEJOB member ??? RACF has no idea. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Changing logon behavior using RACF
On 2/9/2007 12:00 PM, Steve Rawlins wrote: I work at a small company where our z9 is used just for our development and testing, not a production environment. So I sometimes am my own sysadmin, sysprog, security officer, etc. I am trying to edit my user profile so that: 1. When I logon to USS (aka OMVS), I get bash shell by default (instead of having to type bash every time I logon, as I do now) 2. When I logon to TSO, I want to execute a certain CLIST. I have tried to accomplish both of the above for myself via RACF. In neither case does my change take. Anybody recognize this RACF behavior? Am I supposed to push the change out somehow? 1. For the bash change, even though RACF shows that my change has taken effect: OMVS INFORMATION UID= 007571 HOME= /u/sjr PROGRAM= /usr/lpp/oss/bin/bash nothing happens, i.e. my logon default is still sh and I end-up having to type bash every logon. Same happens for the two other users here for whom I have tried to set-up the same logon behavior. That's really a question about z/OS UNIX System Services, not RACF. I'll guess, however, that the PROGRAM specification applies when you logon to z/OS UNIX, e.g., via telnet or rlogin. Specifying OMVS under TSO is not really the same as logging on. But again, that's a guess. Someone here may know, but if not I suggest you ask on the MVS-OE list. 2. For the TSO CLIST change. I have tried updating the TSO command. EX USER.CLIST(STARTUP) RACF seems to have taken this COMMAND update, but when I log-off and log-in again - it's gone. As if I'd never tried updating RACF this way. Also not really a RACF question, but one about how TSO/E operates. I believe that TSO/E documents that changes made to a user's TSO segment while the user is logged on may be lost when the user logs off, as TSO/E rewrites the TSO segment during LOGOFF processing. So, don't try to do an ALTUSER to change your TSO segment. Instead, just specify the command on the full-screen logon panel and TSO/E will save it for you. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Missing fixes
On 2/7/2007 3:24 PM, R.S. wrote: I just get held by two APARs: AK34959 and AK33471. Those APARs can be found ...under PK34595 and PK33471. I guess PKn is APAR number, and AKn is APAR fix number. Those APAR describe fixes UK21449 and UK21373 respectively. However ...I cannot download those fixes, because IBM system Download fixes claims they do not exist. I tried the same on ShopzSeries. UK21373 is available, UK21449 is not. I also tried to make an oredr with PK and AK numbers. Result: not found. I tried ServiceLink: both PTFs are unavailable. Any clue ??? Contact the IBM Support Center and request the fixes. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Missing fixes
On 2/7/2007 4:05 PM, Patrick O'Keefe wrote: The entry for UK21449 gives no info whatsoever except that it is open. Not even an associated APAR identifier. (Maybe it's a security exposure APAR so they are being secretive.) RETAIN shows the APAR number when I browse that PTF number. And no, the APAR is not related to system integrity or security. (In any case, as far as I know the PTF will always link to the APAR, but for a security/integrity APAR you won't be able to see the APAR itself.) Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Changing the SMF SID Parameter
On 2/6/2007 5:32 PM, Eric Bielefeld wrote: My question is, will this affect anything? Is there any program products that could be affected by changing the SID? I read the whole chapter in the Init Tuning Reference, and I didn't see anything that would matter to us. RACF allows you to specify conditional access list entries for PROGRAM profiles that grant access to run a program WHEN(SYSID(sid)). Changing the SID might affect some users' access to programs on that system if your security administrators have used that capability. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Audit failures(update)
On 2/7/2007 5:18 AM, [EMAIL PROTECTED] wrote: I have defined the dataset profile as AUDIT(FAILURES(UPDATE)). When will log the failure to SMF. That specification will cause auditing only for attempts that need UPDATE access or higher (failing attempts to change the data in the data set, or (for example) to delete the data set). Failing attempts to READ the data set would not cause auditing, nor would any successful attempts to READ or UPDATE the data set. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMP/E in TSO (was: Why AUTHPGM?)
On 2/4/2007 4:53 PM, Paul Gilmartin wrote: On Sat, 4 Nov 2006 09:16:44 -0500, Gilbert Saint-Flour wrote: The system closes DCBs at end-of-task. You and IBM are in agreement, at least insofar as this should happen; they've taken APAR OA19801 for a case where it doesn't. Interesting -- the APAR seems to say that an attempt is made to flush the buffer after the task has already terminated. This seems to leave the file at least partially open, but closed enough that I could FREE the DDNAME. I'd almost expect a program check from an attempt to manipulate previously freed resources. I think I interpret the APAR text a little differently than you do, gil. To me it seems like the UNIX task termination code runs before the DCB-related task termination code, and so has already deleted the UNIX-related information that underlies the DCB, before the DCB-related code can flush the buffers and close the DCB. Thus the 614 abend that the APAR talks about. So, the system is closing the DCB during task termination, but we have the situation where two things need to happen in a particular order, and they're out of order right now. Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
