Top Secret

I'm about to start using the SPI resource class for securing CEMT.  SPI is defined in the RDT, but there are no permissions or ownership created yet.  I tried to create an owner for SPI(*), but TSS told me that was an unacceptable resource name.  I assume that's because SPI is defined as NOMASK.

So is there any reason I should not change the definition to MASKABLE?  I presume that would enable me to assign ownership as SPI(*), which is preferable to assigning SPI(A), SPI(B), SPI(C) and so on.

I note in the manual that once I make this change it cannot be reversed, so I want to think it through first.  Are there any gotchas?

Hi Bob,

- What is your intention to make SPI resclass maskable ?

- If you want to have all SPI resources protected, consider to add DEFPROT to the reslass in your RDT .

- If you would like to tier the SPI permissions per CICS-regions resp. CICS facilities, you might use FAC suboption in the permit command. Unfortunately CA Top Secret does not support at all the CICS System Initialization Parameter SECPRFX, which would offer a smarter and more flexible approach for security admin. See https://communities.ca.com/ideas/235738957-make-top-secret-cics-obey-cics-system-initialization-parameter-secprfx

kind regards,

Josef

Hi, Josef.  My main reason for considering MASKABLE for SPI is what I said above:  It'd be easier to assign ownership of SPI(*) one time than to have to do it 26 times (SPI(A), SPI(B), SPI(C) etc).  Or 19 times, that being the number of starting letters in the list of SPI resource names.  I gather DEFPROT will enable TSS to forbid access to SPI resources without assigning ownership first, and that's great.  But even when I do that, I can't do permits without ownership, right?  And in any case I want the permissions, too, to start out universal:  My goal, at least to start, is to PER(ALL) SPI(*) ACC(INQUIRE) and PER(CICSADM) SPI(*) ACC(ALL).  I don't see how to accomplish that in a NOMASK resource.

See more below.

Hi Bob,

did you try an ADD(OWNER) SPI(**) and PER(USER) SPI(**) ACC(….) ? Maybe this works even the resclass in RDT has ATTR NOMASK.

I believe, that MASK just allows/enables the masking characters (+,*,% etc.) to be specified in a resname and demands 2 bytes minimum prefix. With NOMASK these charaters are taken as is, and the resname is seen as prefix. (there are some exceptions like IBMGROUP...  ) with 1 byte minimum prefix .

by the way: you can establish audit also for resources, which do not (yet) have an owner. So, if useful, you could try to ADD(AUDIT) SPI(A) before you establish ownership. 

Kind regards,

Josef

Hey, that worked!  Thanks, Josef.  I may be back on track now...or I may be back with more questions :-).

The Top Secret User's Guide Section 

Variable Character Substitution 

The following rules apply to masking:
* For resource classes that support masking, an ADD command must specify a
minimum of two characters
* An ADD command that contains a masking character must start with a masking
character
* A resource name that starts with a non-masking character cannot contain
a masking character in the second position

****************************************************************************************

Example

A resource name can not be permitted unless it is owned. So in order
to permit a resource that starts with a masking character, it would have
to be owned. This does NOT define all resource names that match the mask.
(In other words, TSS ADD(dept) JESJOBS(+OBCLASS.*.X) does not protect
AOBCLASS.*.X, BOBCLASS.*.X, etc. A separate TSS ADD command would be needed
to define each of these.) What the TSS ADD(dept) JESJOBS(+OBCLASS.*.X)
command does do is allow you to permit this resource to an acid
(ie TSS PERMIT(acid) JESJOBS(+OBCLASS.*.X) ACC(acc) ).

Hi Bob,

There are no "gotchas" but the one road block to changing from NOMASK to MASK is that all permits would have to be revoked and the ownership removed before changing from NOMASK to MASK.  In your case you said you have not issued any permits so that simplifies the process.  For predefined resource classes with RESCODEs 040 to 0FF, a class that was originally defined as NOMASK can be changed to MASK.   Here is a link to changing about changing from NOMASK to MASK:

 Change Non-Maskable Resources to Support Masking - CA Top Secret® for z/OS - 16.0 - CA Technologies Documentation 

Cheers,

 ~Eileen~

Bob,

Contrary to public opinion, there are some gotchas, as detailed in the implementation plan following.

There are no restrictions on switching back and forth between "NOMASK" and "MASK".

The implementation steps are as follows -

• Revoke all existing resource access permits associated with the resource class ID to be revised;
• Remove all resource ID ownerships associated with the resource class ID to be revised;
• If you make use of SECCACHE -
  • Deactivate SECCACHE -
    • TSS MODIFY(SECCACHE(OFF))
• TSS MODIFY(SYNCH)
• TSS REPLACE(RDT) RESCLASS({resource-class-ID-8}) ATTR([NO]MASK)
• TSS MODIFY(SYNCH)
• If you make use of SECCACHE -
  • Reactivate SECCACHE -
    • TSS MODIFY(SECCACHE(...))
• Add all desired resource ID ownerships associated with the resource class ID that has been revised;
• Issue all desired resource access permits associated with the resource class ID that has been revised.

John P. Baker

Hi, John.  I did see all that in the User's Guide; since no SPI resources have yet been owned or permitted at this installation, I wasn't counting that as a gotcha, but I guess it would be for someone going into this without knowing it.

About being able to switch back, it says in the same section "Note: A class that is defined as MASK cannot be changed to NOMASK."  If you know the manual's wrong, please let me know (and how you know) and I'll look closer.

Bob,

I ran a series of tests using -

TSS REPLACE(RDT) RESCLASS({resource-class-ID-8}) ATTR(MASK)

and

TSS REPLACE(RDT) RESCLASS({resource-class-ID-8}) ATTR(NOMASK)

and encountered no problems.

I believe that the issue is that "NO RESOURCES CAN BE OWNED" using that resource class ID when changing from "ATTR(MASK)" to "ATTR(NOMASK)".

It is unclear to me whether that rule holds in the reverse scenario.

I will perform some additional testing and let you know what I discover.

John P. Baker

I've read the above replies (thank you one and all).  I'm now combining something from Josef with something from Robert Lynch:

1) I read the section that Robert quoted, but I missed the part about two characters being required in the ADD statement.  So I guess the lesson here is that I would have to ADD(owner) SPI(**), rather than SPI(*)?

2) Yet the manual makes clear that this wouldn't protect all SPI resources; it only makes it possible to PERMIT SPI(**)...or maybe SPI(*); I'll experiment.

So if I do the following (and remember that SPI has no ownership or permissions yet):

  rep(rdt) resclass(spi) attr(mask)
  add(owner) spi(**)
  per(all) spi(*)
  per(CICSADM) spi(*) acc(all)

...will all SPI calls then go through one or the other of those two permissions?  Or must I add DEFPROT as well?  Comments welcome.

Bob,

If you add ATTR(DEFPROT), then all resource IDs in that resource class ID will be protected without any requirement for those resource IDs to be owned.

However, you cannot issue permits until you establish ownership.

John P. Baker