Re: Data Set Name "Hiding"

On 2/23/2006 6:59 AM, Jim Marshall wrote:
My Security folks are eager to have us implement something called "Dataset
Name Hiding". This will hide dataset names from a user's view if they do
not have the necessary security authority for these files. I am not sure of
all the details as to what RACF permissions are needed "to see" a file.

Has anyone implemented or evaluate this (most likely) new feature. What
were the effect of implementation. My sense is there might be an
implication of more processor usage depending on what z/OS needs to do to
check if a user may or may not see a line to be displayed on their screen.
I believe this facility is within TSO with ISPF.

First, I'll assume you're only interested in hiding the names of MVS data sets, as opposed to z/OS UNIX files or directories.

As documented, that function applies to VTOC listing (e.g. via ISPF 3.4) and to catalog listing (e.g., via ISPF 3.4, CSI, or LISTCAT) where the user provides a generic filter rather than a specific data set name.

The security requirements differ depending on whether you're talking about VTOC listing or catalog listing.

For catalog listing, if the user has READ access to the data set then he will be able to see its name.

For VTOC listing, the user can get the necessary authority via either:
(a) READ access to FACILITY resource STGADMIN.IFG.READVTOC.volser or
(b) READ access to the data set itself.

Note that with name hiding inactive (SETR NOMLNAMES, the default) there is usually -no- security check for the individual entries when reading a VTOC. There is only a security check when reading a catalog if the user has asked for sensitive information (usually no check with ISPF 3.4, for example, but sometimes a check with LISTCAT or CSI).

So, if you enable name hiding (SETR MLNAMES) you will certainly have more overhead for doing VTOC or catalog listing, both in terms of CPU and potentially RACF I/O processing for loading and processing generic profiles.

For some more info, see
(1) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/e0z2e121/3.8.2.1?SHELF=&DT=20060125172015 or http://makeashorterlink.com/?K2A5321BC

(2) http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2d440/1.5.1.4?SHELF=&DT=20050602124524 or http://makeashorterlink.com/?M6B5261BC

Walt Farrell, CISSP
z/OS Security Design, IBM

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.

Relevant Pages

  • Re: restricted area
    ... Hiding the area, go to this area page, Manage Security -> Donot Inherit ... remove all default users -> Select the domain users one by one or by domain ... The audience will filter the view of it so they ...
    (microsoft.public.sharepoint.portalserver)
  • Re: exec of a fd instead of pathname
    ... *just not in every security context they might ... Removing or cleverly hiding, say, snoopaccomplishes litte: ... hiding system executables from ordinary users is rather ... encrypting them ...
    (comp.unix.solaris)
  • Re: Hide email from spammers
    ... >>serve the purpose of hiding the email address? ... Next I need to learn what the "security" issues are that people keep ... I found one called Jack's FormMail at ...
    (comp.lang.php)
  • Re: Stealth vs. Blocked
    ... >> Stealth does not improve your security. ... >Other than the false sense of security, do you not think that every ... a bunker hiding in that cornfield would be nice. ... behind stealth, ...
    (alt.computer.security)
  • Re: Stealth vs. Blocked
    ... >> Stealth does not improve your security. ... >Other than the false sense of security, do you not think that every ... a bunker hiding in that cornfield would be nice. ... behind stealth, ...
    (comp.security.firewalls)