In the previous syntax, RULE_SET was a simple declarative command. Subsequent RULE commands used the SET(rule_set) parameter to group themselves into a rule_set, or control. The installation could make a control more restrictive by coding RULE xxx SET(rule_set) commands after the rule_set was declared, as long as the new rule (xxx) was not defined before. And installation could also use SUPPRESS RULE=yyy to disable parts of a control. We used this extensively to tailor the zSecure STIG implementation to an installations naming (or otherwise) convention.
In the new syntax, RULE_SET / END_RULE_SET creates a context that provides parameters for RULE commands in the context. Jeroen's design would preclude installations from adding RULEs to zSecure's standard CONTROLs, thus limiting the ability for installations to tailor these CONTROLs to their conventions. As a consequence, customers would have to modify SCKRCARL members and lose improvements to those members in zSecure's maintenance.
Jeroen's proposale to deny a second RULE_SET command with the same name (as the syntax manual could interpreted) is possible iff the RULE SET() parameter is respected for RULE commands that are issued outside of a CONTROL / END_CONTROL block. This used to be the way to link a RULE into a RULE_SET, and could be explicitly supported (again) to add installation defined rules into a CONTROL. The current syntax does not explicitly allow or deny this parameter for the new syntax, so I suggest to document its use.
------------------------------
Rob van Hoboken
------------------------------
Original Message:
Sent: Wed July 26, 2023 02:37 AM
From: Jeroen Tiggelman
Subject: Overriding a RACF_ZOS_STIG V8.10
Hi Brian,
Rob demonstrated that there is a bug in the current processing, and development has opened a Bug ZSEC-14450 for it. Without further action, that will probably get fixed sometime, but the thread above shows that there can be discussion as to what the most appropriate fix would be. Rob thinks merging the controls would be preferable. To have the program behave as documented, a syntax error would be appropriate. I think that you want the original functionality back of suppressing the supplied rule and replacing it with a local one. Overall, my current thinking is that merging is the thing that absolutely should not happen to avoid confusion as to what is being tested and that a syntax error is appropriate when the specification is ambiguous like that as a first-order improvement, and that we should see how to restore the option of replacing a rule on the next level (assuming for now that that was intended behavior, I did not verify that yet; if not, that would be a discussion point).
[I am positive we had an intended facility for suppressing rules from a standard, and also an option for you to add new rules; what I don't immediately recall is if we would allow the same name, and when I think about it I am not convinced it is particularly desirable.]
By default a fix would make it into our main release level at some point. If you would want to be sure of a fix on your current release level, it would be appropriate to request an APAR for that purpose via a Case. That also tells us that this really bugs you and that we should give this Bug priority. (Furthermore, the APAR would tell other clients that looked for known problems that this one exists.) It would also give us a clear formal communication path. :-)
Regards,
------------------------------
Jeroen Tiggelman
IBM - Software Development and Level 3 Support Manager IBM Security zSecure Suite
Delft
Original Message:
Sent: Mon July 24, 2023 11:31 PM
From: Brian Mills
Subject: Overriding a RACF_ZOS_STIG V8.10
Tom and Ron
Thanks for your replies. Would it be best to open a case with support?
For completeness I will include the equivalent V6 details for Control ZUSS0012. The V6 result is what I was expecting for the V8 control RACF-US-000150.
STDRULES
STDGOALS - The results for each version is what I expected to see.
SE@@ZU12
sese@@u150
Regards
------------------------------
Brian Mills
Original Message:
Sent: Fri July 21, 2023 01:03 AM
From: Rob van Hoboken
Subject: Overriding a RACF_ZOS_STIG V8.10
Hi Tom, the syntax documentation of STANDARD tells us that the name defined on a RULE_SET must be unique within its context, but can be duplicated within different STANDARDs or VERSIONs.
In the new syntax (2022), all names defined for DEF_REF, DEF_STD, DOMAIN, RULE, CONTROL or RULE_TEST, and GOAL or TEST must be unique within their context.
A CONTROL/RULE_SET name can be part of multiple STANDARD and VERSION statements.
The Summary line in Brian's screen shot shows that the STANDARD and VERSION are identical, so it should be impossible for the RULE_SET to be shown twice.
It looks like the new syntax parser does not detect the first specification of the RULE_SET, and does not merge the 2nd specification into the 1st (which would be my preferred behavior), or flag the new specification down as syntax error (which would prevent local customization of goals/tests).
------------------------------
Rob van Hoboken
------------------------------