IBM Security Z Security

 View Only
  • 1.  higher access in generated commands

    Posted Tue June 09, 2020 10:15 AM
    ​Hello,

    I'm trying to combine the accesses of 2 groups grpA & grpB into a new one (newGrp).
    I'm able to generate PERMIT commands with:
    newlist type=racf dd=ckrcmd nopage retain
    define #acc(aclaccess)  subselect acl(id=(grpA,grpB))
    select class=general segment=base  acl(id=(grpA,grpB))
    sortlist 'PE' key(0) 'CLASS(' ! class(0) ! ') ID(newGrp) ACC(' ! #acc(0) ! ')'
    This works ... but what should I do to only get the higher access when both ids are defined in the same ACL?
    example:
    PE TEST.FOR.CARLA CLASS(FACILITY) ID(newGrp) ACC(READ) 
    PE TEST.FOR.CARLA CLASS(FACILITY) ID(newGrp) ACC(ALTER)

    Many thanks for your help,

    ------------------------------
    Alx.
    ------------------------------


  • 2.  RE: higher access in generated commands

    Posted Tue June 09, 2020 10:51 AM
    Edited by Jeroen Tiggelman Tue June 09, 2020 11:31 AM
    Hi Alex,

    Without switching to a completely different approach, I think this will involve duplicating the newlist for each access level.

    This is because SUBSELECT is an output processing option and cannot influence the selection.

    You can change the ACL selection clauses for the various newlists to
    acl(id=(grpA,grpB) access=level)
    for the various access levels.

    By itself this will of course lead to the same results.

    However, then you can add in an exclude command to omit the profiles for which there is also a higher level.
    Like:
    select class=general segment=base acl(id=(grpA,grpB) access=read)
    exclude c=general segment=base acl(id=(grpA,grpB) access>read)

    Note that this only provides a simple answer to your question. It does not eliminate generating duplicate commands, and it takes no precautions for conditional ACL entries.

    I hope this begins to help.

    Regards,

    --Jeroen

    ------------------------------
    Jeroen Tiggelman
    Software Development and Level 3 Support Manager IBM Security zSecure Suite
    IBM
    Delft
    ------------------------------



  • 3.  RE: higher access in generated commands

    Posted Thu June 11, 2020 03:12 AM
    Thank you Jeroen. 
    I'll go for another approach for the reasons you mentioned (duplicates, no conditional access) and also for the lack of elegancy :)

    ------------------------------
    Alx
    ------------------------------



  • 4.  RE: higher access in generated commands

    IBM Champion
    Posted Wed June 10, 2020 03:16 AM
    Edited by Rob van Hoboken Wed June 10, 2020 03:24 AM
    I agree with Jeroen, a whole new approach is needed, one where individual PERMITs are available as selectable entries.  CARLa offers such a data store: RACF_ACCESS.
    Next we have to find the highest value of a field in two similar entries, that is the SUMMARY statistic MAX.
    Putting these together we get:

    newlist type=racf_access dd=ckrcmd nopage retain
    define high_access max(access)
    select class=facility id=(grpA,grpB)
    summary 'PE' profile(0) 'CLASS(' | class(0) | ')',
    'ID(newGrp) ACC(' | high_access(0) | ')' count(nd)

    Note: RACF_ACCESS does not know about (pseudo) class GENERAL.  You can either select the specific classes you need, or write

    select class<>(DATASET,GROUP) id=(grpA,grpB)

    ------------------------------
    Rob van Hoboken
    ------------------------------


  • 5.  RE: higher access in generated commands

    Posted Thu June 11, 2020 03:13 AM
    Many thanks Rob.
    I'm glad to have post my question I learned something today. :)


    ------------------------------
    Alx
    ------------------------------



  • 6.  RE: higher access in generated commands

    IBM Champion
    Posted Thu June 11, 2020 03:26 AM
    There are some details about RACF_ACCESS I forgot to mention.  RACF_ACCESS can be a life saver when you have to report profiles at the access list entry level, and in compliance reporting.  There are extra fields and field values that you can find documented in the Syntax manual (and with the IN.D menu in ISPF).

    The ACCESS field also contains clever information in addition to the normal access levels you use in PERMIT commands, such as QUALOWN (the ability to access resources when your user ID or group operations privilege matches the qualifier of the data set).  You should add an ACCESS<>QUALOWN to your SELECT command.

    The ID field contains information about the UACC, by setting ID='-UACC-', access via the Global Access Table through ID=' any -', and 2 lesser important values.  When using RACF_ACCESS for other reports, users would explicit exclude those using ID<>-*

    Also, RACF_ACCESS simulates RACLIST processing, i.e., the combination of profiles with grouping profiles.  Such RACLISTed entries are indicated by flag field RACLIST_MERGE, and should be excluded when only real profiles are needed.

    ------------------------------
    Rob van Hoboken
    ------------------------------