Top Secret

 View Only
  • 1.  How does the OS interact with the bit values in the RDT?

    Posted Oct 11, 2018 02:18 PM

    Something I've wondered for a long time but haven't found in the documentation (although I expect it's there somewhere):  When I look at the definition of a resource class in the RDT, I see a bunch of hex values in the ACCESS line(s), for example:

      ACCESS = NONE(0000),FETCH(8000),UPDATE(6000),READ(4000),WRITE(2000)
      ACCESS = CREATE(1000),SCRATCH(0800),CONTROL(0400),INQUIRE(0080)    
      ACCESS = SET(0040),ALL(FFFF)

    One thing is immediately clear:  Each of these values is a bit or series of bits, and they can interact:  ALL, for example, contains all the access levels because it's hex Fs, and UPDATE comprises both READ and WRITE because a hex 6 covers the 4 and the 2.

    Ok, I get that.  But how does this interact with the operating system?  z/OS, I suppose, thinks in RACF, and in RACF there are only four access levels.  So how does the OS ask whether a user has SET access to a dataset, for example?  If RACF knows of only four access levels, what utility can be granted by all these other access levels (as defined to TSS) if the OS cannot use them?

    I guess what I'm asking is "How does it work?".  Someday I may have to create a user-defined class and it seems like it'd be a handy thing to know.



  • 2.  Re: How does the OS interact with the bit values in the RDT?

    Broadcom Employee
    Posted Oct 12, 2018 09:37 AM

    Hi Bob,

     

    SET access for a dataset is used in conjunction with CICS. If XFCT=YES and DSNCHECK=YES are set on the CICS facility in CA Top Secret, the DATASET resource is used for FILE or DATASET keywords when INQUIRE or SET actions are used with the CEMT transaction. For example, with XFCT=YES and DSNCHECK=YES set on the CICS facility:

     

    CEMT SET DATASET(xxxx.yyyy)

     

    requires SET access to dataset xxxx.yyyy.

     

    CEMT INQUIRE DATASET(xxxx.yyyy)

     

    requires INQUIRE access to dataset xxxx.yyyy.

     

    Best regards,

    Bob Boerum



  • 3.  Re: How does the OS interact with the bit values in the RDT?

    Posted Oct 12, 2018 12:43 PM

    My question was more general than that; SET was just an example.  But based on your reply, Bob, I think I understand now.  The bits in the RDT's ACCESS values do not interact with the OS.  Instead—check my guesses, here—

     

    1) The OS asks its questions using character strings such as "READ", "CONTROL", "SET" etc.  For any given resource class there's a set of access strings the OS might use in its query to the security app; let's call that set the "OS-defined access labels".

     

    2) TSS includes each of the OS-defined access labels in the RDT's ACCESS values (for a given resource class).

     

    3) But TSS also assigns each of these labels one or more bits in a two-byte field.  This enables the admin to create, if desired, other labels to which he assigns one or more of the OS-defined bits.  These new labels can be used in PERMIT statements.

     

    So, for example, the PANEL class has CONTROL (0400), SCRATCH (0800), CREATE (1000), WRITE (2000) and READ (4000); it also defines UPDATE as a combination of READ and WRITE (6000).  If I were assigning a ton of permissions using CONTROL and SCRATCH—don't ask me why, I'm just making up an example—I could create a new access level BRIDGES, give it the bit value 0C00, and then PERMIT(acid) PANEL(whatever) ACCESS(BRIDGES) instead of ACCESS(CONTROL,SCRATCH).  And if for some reason I had an irrational hatred of the word CREATE, I could define another named INVENT, give it the same bit value as CREATE (1000), and thereafter PERMIT(acid) PANEL(whatever) ACC(INVENT) would work just as well as ACC(CREATE).

     

    How's that?



  • 4.  Re: How does the OS interact with the bit values in the RDT?

    Broadcom Employee
    Posted Oct 15, 2018 03:16 PM

    Hi Bob,

     

    The PANEL class is a predefined resource class. The access level list can not be changed for predefined resource classes. It can only be changed for user defined resource classes. For a user defined resource class, you can create a new access level of BRIDGES with a hex value that includes other access levels and then permit that access level. 

     

    NOTE: When an access level is to include other access levels, the access list in the RDT must be in hexadecimal descending order. For example, user defined resource class BOB is to have the following access levels: CONTROL (0400), SCRATCH (0800), CREATE (1000), WRITE (2000) and READ (4000) and another access level of BRIDGES that includes CONTROL and SCRATCH. The ACLST when defining or updating the RDT entry for BOB should be:

     

    ACLST(ALL=FFFF,READ=4000,WRITE=2000,CREATE=1000,BRIDGES=0C00,SCRATCH=0800,CONTROL=0400,NONE=0000)

     

    Best regards,

    Bob Boerum