Re: XCFAS and TRUSTED
> TRUSTED is a way for the systems programmer to make it harder for > an over-zealous security officer to break the system. Mit der Dummheit kämpfen Götter selbst vergebens But that applies equal well to a security officer who is too lax. It is essential that he be trained to understand the ramifications of decisions that he makes on his own and know when to consult specialists. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Leonard D Woren [ibm-main...@ldworen.net] Sent: Monday, August 21, 2023 3:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCFAS and TRUSTED Andrew Rowley wrote on 8/20/2023 4:40 PM: > On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: > >> Secondly, when IBM states that a task should be given the attribute >> of Trusted, then I take it to mean that IBM is saying that the task >> can be trusted that this attribute cannot be the source of an >> exposure for that task. > > I think when IBM says a task should be given trusted, it's a > stronger statement than that. > > I take it to mean that the task should never be denied access by the > security system, and any denial of access risks the stability or > operation of the system. The endpoint of the last clause above is the inability to IPL the system. My vague recollection from back when I was a senior systems programmer is that you set as TRUSTED any task which is necessary in order to get enough of the system up and running so that you can logon and fix problems. If JES2 or VTAM or (long list) fails before you can logon, have fun fixing it. This was before there was such a proliferation of system address spaces, but I figure the same applies. Putting on my cynical hat (which I never really take off), TRUSTED is a way for the systems programmer to make it harder for an over-zealous security officer to break the system. /Leonard -- 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: XCFAS and TRUSTED
Andrew Rowley wrote on 8/20/2023 4:40 PM: On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: Secondly, when IBM states that a task should be given the attribute of Trusted, then I take it to mean that IBM is saying that the task can be trusted that this attribute cannot be the source of an exposure for that task. I think when IBM says a task should be given trusted, it's a stronger statement than that. I take it to mean that the task should never be denied access by the security system, and any denial of access risks the stability or operation of the system. The endpoint of the last clause above is the inability to IPL the system. My vague recollection from back when I was a senior systems programmer is that you set as TRUSTED any task which is necessary in order to get enough of the system up and running so that you can logon and fix problems. If JES2 or VTAM or (long list) fails before you can logon, have fun fixing it. This was before there was such a proliferation of system address spaces, but I figure the same applies. Putting on my cynical hat (which I never really take off), TRUSTED is a way for the systems programmer to make it harder for an over-zealous security officer to break the system. /Leonard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
Good point. Just to clarify: 1. I have no problem with giving XCFAS the TRUSTED attribute. I have several STARTED class profiles with the attribute, however everytime I checked IBM doco before that. Just to be auditor-proof. ;-) So, I asked just to be sure that I can answer "yes, it is documented - it is IBM recommendation". 2. (omitted) 3. In my case it was no problem to re-IPL the system. However it is possible, someone has to wait for service window. In that case a bunch of PERMITs could save the situation. Of course I still support the XCFAS should be TRUSTED. This is matter or temporary solution only. Thank you all gentlemen for the answers! -- Radoslaw Skorupka Lodz, Poland W dniu 21.08.2023 o 15:22, Robert S. Hansel (RSH) pisze: To add to this discussion, it is my understanding that when IBM tests new version of z/OS, they do so with the tasks named in the documentation with TRUSTED authority. Since they have TRUSTED, IBM does not determine or document what access authorization the tasks require. If you choose to run z/OS with any of these tasks without TRUSTED, you are doing so in a state IBM has not tested nor provided access authorization guidance; hence, you do so at your own risk and may encounter access authorization issues that could be detrimental to the system. I used to advocate for not using PRIVILEGED or TRUSTED for any tasks but relented once I learned of this for the sake of system availability. I now warn clients whenever I discover any of these tasks running without TRUSTED. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -Original Message- Date:Mon, 21 Aug 2023 09:40:20 +1000 From:Andrew Rowley Subject: Re: XCFAS and TRUSTED On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: Secondly, when IBM states that a task should be given the attribute of Trusted, then I take it to mean that IBM is saying that the task can be trusted that this attribute cannot be the source of an exposure for that task. I think when IBM says a task should be given trusted, it's a stronger statement than that. I take it to mean that the task should never be denied access by the security system, and any denial of access risks the stability or operation of the system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
To add to this discussion, it is my understanding that when IBM tests new version of z/OS, they do so with the tasks named in the documentation with TRUSTED authority. Since they have TRUSTED, IBM does not determine or document what access authorization the tasks require. If you choose to run z/OS with any of these tasks without TRUSTED, you are doing so in a state IBM has not tested nor provided access authorization guidance; hence, you do so at your own risk and may encounter access authorization issues that could be detrimental to the system. I used to advocate for not using PRIVILEGED or TRUSTED for any tasks but relented once I learned of this for the sake of system availability. I now warn clients whenever I discover any of these tasks running without TRUSTED. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -Original Message- Date:Mon, 21 Aug 2023 09:40:20 +1000 From:Andrew Rowley Subject: Re: XCFAS and TRUSTED On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: > Secondly, when IBM states that a task should be given the attribute of > Trusted, then I take it to mean that IBM is saying that the task can be > trusted that this attribute cannot be the source of an exposure for that task. I think when IBM says a task should be given trusted, it's a stronger statement than that. I take it to mean that the task should never be denied access by the security system, and any denial of access risks the stability or operation of the system. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
> Not worth the risk, in my view (our security group disagreed!) In the Army they taught me that unauthorized denial of service is also a security breach. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Andrew Rowley [and...@blackhillsoftware.com] Sent: Sunday, August 20, 2023 7:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCFAS and TRUSTED On 20/08/2023 8:53 pm, Mike Cairns wrote: > I worked at one site many years ago where the local specialist had actually > tested across multiple IPL's the necessity for each and every one of these > tasks to actually have the TRUSTED attribute and the conclusion was that many > of these did not actually need to be TRUSTED and could manage perfectly fine > using normal RACF access to resources granted via permissions to profiles. I worked at a site which did a similar exercise. The risk is: 1) If the doc says it should be trusted, IBM are free to add functions that require access to other resources without documentating them. It's possible that IBM don't even consider what access would normally be required for an address space they specify as TRUSTED, or test it without TRUSTED. 2) There may be functions that are invoked only in unusual circumstances, so you only find out that access is missing when you are already dealing with a problem. Not worth the risk, in my view (our security group disagreed!) -- Andrew Rowley Black Hill Software -- 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: XCFAS and TRUSTED
Classification: Confidential The TRUSTED attribute usually comes along with an ID that cannot be "logged on to", so, it is not available for manipulation. By this time, auditors should be fully conversant in te trusted attribute. I don't see an issue here. My USD 0.02 worth. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Saturday, August 19, 2023 4:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: XCFAS and TRUSTED [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I'm setting up some sysplex and found some healthcheck is not OK, the reason was XCFAS was not TRUSTED. Questions: 1. Is the requirement of the TRUSTED status documented anywhere? That's good to know before auditor asked. 2. Is there any way to fix it without reIPL? 3. Somehow related to 2. - IMHO actually it is not matter of the attribute, but the matter of access to some resources. Are the resources needed for XCFAS documented/known ? -- 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 ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
Andrew, You may be right that IBM are trying to state something stronger. My point is that safety is a minimum requirement for an IBM recommendation. I have found several cases where IBM has specified a higher level of access than is necessary. For example, IBM states that FTP needs UID(0) to function, whereas many find this is unnecessary. So while I do not run my FTP with UID(0), I am reasonably confident it is safe to do so. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: 21 August 2023 00:40 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCFAS and TRUSTED On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: > Secondly, when IBM states that a task should be given the attribute of > Trusted, then I take it to mean that IBM is saying that the task can be > trusted that this attribute cannot be the source of an exposure for that task. I think when IBM says a task should be given trusted, it's a stronger statement than that. I take it to mean that the task should never be denied access by the security system, and any denial of access risks the stability or operation of the system. -- Andrew Rowley Black Hill Software -- 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: XCFAS and TRUSTED
On 21/08/2023 9:28 am, Lennie Dymoke-Bradshaw wrote: Secondly, when IBM states that a task should be given the attribute of Trusted, then I take it to mean that IBM is saying that the task can be trusted that this attribute cannot be the source of an exposure for that task. I think when IBM says a task should be given trusted, it's a stronger statement than that. I take it to mean that the task should never be denied access by the security system, and any denial of access risks the stability or operation of the system. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
I understand your security group's point of view. I understand yours as well. When considering this there are a couple of extra points. Firstly, when a task is given the Trusted attribute then it effectively has UID(0) as well as gaining access via each RACF check. Secondly, when IBM states that a task should be given the attribute of Trusted, then I take it to mean that IBM is saying that the task can be trusted that this attribute cannot be the source of an exposure for that task. Some tasks should not be given the Trusted attribute as it could lead to exposures; or in other words, they cannot be trusted. So I take it, that XCFAS can be trusted. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Andrew Rowley Sent: 21 August 2023 00:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: XCFAS and TRUSTED On 20/08/2023 8:53 pm, Mike Cairns wrote: > I worked at one site many years ago where the local specialist had actually > tested across multiple IPL's the necessity for each and every one of these > tasks to actually have the TRUSTED attribute and the conclusion was that many > of these did not actually need to be TRUSTED and could manage perfectly fine > using normal RACF access to resources granted via permissions to profiles. I worked at a site which did a similar exercise. The risk is: 1) If the doc says it should be trusted, IBM are free to add functions that require access to other resources without documentating them. It's possible that IBM don't even consider what access would normally be required for an address space they specify as TRUSTED, or test it without TRUSTED. 2) There may be functions that are invoked only in unusual circumstances, so you only find out that access is missing when you are already dealing with a problem. Not worth the risk, in my view (our security group disagreed!) -- Andrew Rowley Black Hill Software -- 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: XCFAS and TRUSTED
On 20/08/2023 8:53 pm, Mike Cairns wrote: I worked at one site many years ago where the local specialist had actually tested across multiple IPL's the necessity for each and every one of these tasks to actually have the TRUSTED attribute and the conclusion was that many of these did not actually need to be TRUSTED and could manage perfectly fine using normal RACF access to resources granted via permissions to profiles. I worked at a site which did a similar exercise. The risk is: 1) If the doc says it should be trusted, IBM are free to add functions that require access to other resources without documentating them. It's possible that IBM don't even consider what access would normally be required for an address space they specify as TRUSTED, or test it without TRUSTED. 2) There may be functions that are invoked only in unusual circumstances, so you only find out that access is missing when you are already dealing with a problem. Not worth the risk, in my view (our security group disagreed!) -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
"Setting Up A Sysplex" mentions the previously cited suggestion that XCFAS be TRUSTED so ARM will work. It also mentions using TRUSTED so XCF can access ICSF services (for CF structure encryption) and BCPii services (so XCF can automatically detect and isolate failed systems). A search of the book for the term "trusted" quickly locates these mentions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
> Is the requirement of the TRUSTED status documented anywhere? I searched z/OS 2.5 for XCFAS trusted and this was the first hit: https://www.ibm.com/docs/en/zos/2.5.0?topic=tailoring-assigning-racf-trusted-attribute I'd guess that you cannot fix this without re-IPL. You can do the "assignment" but it is probably too late to take effect. I'll defer to others on how much of the "why" is suitable for documentation. The general answer is so that z/OS can do what z/OS needs to do. There is mention of ARM commands as part of the search results. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
Ad 3. XCF_SYSSTATDET_PARTITIONING Note, there are several reason which could result with this check failure. The first is (lack of) BCPii. -- Radoslaw Skorupka Lodz, Poland W dniu 20.08.2023 o 13:03, Robert S. Hansel (RSH) pisze: HI Radoslaw, 1. Here is where the requirement is documented. IBM Manual: MVS Initialization and Tuning Reference (System Tailoring - Assigning the RACF TRUSTED Attribute) https://www.ibm.com/docs/en/zos/2.5.0?topic=tailoring-assigning-racf-trusted-attribute 2. XCFAS will need to be restarted. I do not know if this requires an IPL. 3. Here is mention of a reason why TRUSTED is required. I don't know if this is the only reason. IBM Manual: MVS Setting Up a Sysplex (Planning sysplex availability and recovery - Requirements for participating in automatic restart management) https://www.ibm.com/docs/en/zos/2.5.0?topic=management-requirements-participating-in-automatic-restart What healthcheck reported the issue? Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -Original Message- Date:Sat, 19 Aug 2023 23:53:55 +0200 From:Radoslaw Skorupka Subject: XCFAS and TRUSTED I'm setting up some sysplex and found some healthcheck is not OK, the reason was XCFAS was not TRUSTED. Questions: 1. Is the requirement of the TRUSTED status documented anywhere? That's good to know before auditor asked. 2. Is there any way to fix it without reIPL? 3. Somehow related to 2. - IMHO actually it is not matter of the attribute, but the matter of access to some resources. Are the resources needed for XCFAS documented/known ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: XCFAS and TRUSTED
HI Radoslaw, 1. Here is where the requirement is documented. IBM Manual: MVS Initialization and Tuning Reference (System Tailoring - Assigning the RACF TRUSTED Attribute) https://www.ibm.com/docs/en/zos/2.5.0?topic=tailoring-assigning-racf-trusted-attribute 2. XCFAS will need to be restarted. I do not know if this requires an IPL. 3. Here is mention of a reason why TRUSTED is required. I don't know if this is the only reason. IBM Manual: MVS Setting Up a Sysplex (Planning sysplex availability and recovery - Requirements for participating in automatic restart management) https://www.ibm.com/docs/en/zos/2.5.0?topic=management-requirements-participating-in-automatic-restart What healthcheck reported the issue? Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com -Original Message- Date:Sat, 19 Aug 2023 23:53:55 +0200 From:Radoslaw Skorupka Subject: XCFAS and TRUSTED I'm setting up some sysplex and found some healthcheck is not OK, the reason was XCFAS was not TRUSTED. Questions: 1. Is the requirement of the TRUSTED status documented anywhere? That's good to know before auditor asked. 2. Is there any way to fix it without reIPL? 3. Somehow related to 2. - IMHO actually it is not matter of the attribute, but the matter of access to some resources. Are the resources needed for XCFAS documented/known ? -- 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: XCFAS and TRUSTED
Hi Radoslaw, You can find the list that IBM recommends in the MVS Init and Tuning Guide: https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa231380/$file/ieae200_v2r3.pdf I worked at one site many years ago where the local specialist had actually tested across multiple IPL's the necessity for each and every one of these tasks to actually have the TRUSTED attribute and the conclusion was that many of these did not actually need to be TRUSTED and could manage perfectly fine using normal RACF access to resources granted via permissions to profiles. IIRC we did encounter one or two started tasks that while they were able to run across IPL's without the TRUSTED attribute, there were pseudo-random occurrences of permissions problems that we never did get to the bottom of and IBM could not explain to us either at the time. In the end, we capitulated and granted the TRUSTED attribute. HTH - Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
XCFAS and TRUSTED
I'm setting up some sysplex and found some healthcheck is not OK, the reason was XCFAS was not TRUSTED. Questions: 1. Is the requirement of the TRUSTED status documented anywhere? That's good to know before auditor asked. 2. Is there any way to fix it without reIPL? 3. Somehow related to 2. - IMHO actually it is not matter of the attribute, but the matter of access to some resources. Are the resources needed for XCFAS documented/known ? -- 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
