IBM Security Z Security

Security for Z

Join this online user group to communicate across Z Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  higher access in generated commands

    Posted 06/09/20 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 06/09/20 10:51 AM
    Edited by Jeroen Tiggelman 06/09/20 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 06/11/20 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
    ------------------------------

    Original Message


  • 4.  RE: higher access in generated commands

    Posted 06/10/20 03:16 AM
    Edited by Rob van Hoboken 06/10/20 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 06/11/20 03:13 AM
    Many thanks Rob.
    I'm glad to have post my question I learned something today. :)


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

    Original Message


  • 6.  RE: higher access in generated commands

    Posted 06/11/20 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
    ------------------------------

    Original Message


Related Content