Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Robert S. Hansel (RSH)]

The IBM guidelines for protecting PARMLIB in the RACF Security Administrator's 
Guide indicate that default access of READ is acceptable; however, they qualify 
this as follows: "UACC should be NONE if any members contain passwords, or 
other sensitive  information, such as the ACBPW password in the TSOKEYxx 
member." How often does someone review PARMLIB looking for passwords and the 
like? Most likely never. If you lock it down, there are no worries you've 
missed something.

Whereas most of the configuration information in PARMLIB is in storage for 
anyone to view (e.g., current list of APF libraries), there are a few things in 
fetch-protected storage that require authorization to see, one being the PPT. 
READ access to PARMLIB would let me see what additions and modifications an 
installation has made to the PPT, in particular whether Bypass Password 
Protection or a System Key have been assigned to any program that could be 
exploited. This is a reason for also protecting RACF's DSMON program ICHDSM00 
as it provides PPT information.

I tend to agree with those advocating for least necessary privilege. If access 
isn't explicitly needed, don't provide it, or at least monitor activity to 
discover who is checking you out. Why make it easy for someone to probe your 
system undetected.

The STIG and the RACF SAG should both be amended to indicate the PARMLIB 
concatenation, not just SYS1.PARMLIB.

Regards, Bob

Robert S. Hansel35 years of RACF Experience
Lead RACF Specialist 2021 #IBMChampion
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.twitter.com/RSH_RACF
www.rshconsulting.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Tom Brennan]

I watched a Soldier of Fortran hacking video the other day where Phil 
noted to an audience of Linux folks how odd it was that MVS loaded 
parameters and settings into memory control blocks.  In Unix they say, 
"Everything is a file", which is as odd to me as I'm sure they all felt.


On 2/4/2022 12:35 PM, Matt Hogstrom wrote:

And this IMHO is why the shared access to OS control blocks without access 
controls makes z/OS less secure than a Linux Kernel which is locked down.  I 
think the clarification is cover for “we have a significant read-only 
vulnerability” that needs to be corrected.  Giving away information that shares 
attack vectors makes an attacker’s job easier.

Matt Hogstrom
PGP key 0F143BC1


On Feb 4, 2022, at 06:42, Radoslaw Skorupka  wrote:

IBM's clarification: the information in PARMLIB is accessible to any 
non-privileged user via control blocks, CVT, etc.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Matt Hogstrom]

And this IMHO is why the shared access to OS control blocks without access 
controls makes z/OS less secure than a Linux Kernel which is locked down.  I 
think the clarification is cover for “we have a significant read-only 
vulnerability” that needs to be corrected.  Giving away information that shares 
attack vectors makes an attacker’s job easier.

Matt Hogstrom
PGP key 0F143BC1

> On Feb 4, 2022, at 06:42, Radoslaw Skorupka  wrote:
> 
> IBM's clarification: the information in PARMLIB is accessible to any 
> non-privileged user via control blocks, CVT, etc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Lionel B. Dyck]

And you can find, if you know the control blocks, the smf configuration, the 
dump dataset info, etc.

Nothing is hidden from those who know the keys. 

By locking down PARMLIB you just make it harder - not impossible.

Lock down /etc and see what happens.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
ITschak Mugzach
Sent: Friday, February 4, 2022 01:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

Only few of the parmlib members are represented on mobs control blocks.
Attacker may want to understand how smf is configured, to make sure his 
activity is not recorded, what are the dump dataset mask, racf dataset table 
(if it is a racf shop) and and many other information that help penetrate the 
system.

Remember the first rule of security “need to know”. Most users do not have the 
need. And for the hacker: You want the data, sweat!

ITschak

בתאריך יום ו׳, 4 בפבר׳ 2022 ב-20:25 מאת Mike Shaw :

> Amen Lionel. SHOWZOS is publicly available. Users can write their own 
> REXX code using the STORAGE function to display the active APF list on 
> their system. Security through (attempted) obscurity does not work.
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
>
> On Fri, Feb 4, 2022 at 1:02 PM Lionel B. Dyck  wrote:
>
> > If you want to hide your APF list then you also need to prevent 
> > ISRDDN's APF option as it displays the APF list very nicely. I'm 
> > sure you can protect the SDSF APF command, but can you prevent 
> > SHOWZOS, and other
> tools,
> > from looking in storage and displaying the list for you?  The fact 
> > is
> that
> > you can't.
> >
> > Perhaps you should, if following the STIG rules for PARMLIB, also 
> > prevent user access to /etc in your OMVS and other *nix environments.
> >
> > Lionel B. Dyck <><
> > Website: https://www.lbdsoftware.com
> > Github: https://github.com/lbdyck
> >
> > “Worry more about your character than your reputation. Character is what
> > you are, reputation merely what others think you are.”   - - - John
> Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Edgington, Jerry
> > Sent: Friday, February 4, 2022 11:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS 
> > PARMLIB's?
> >
> > I agree with Ed, for most of the PARMLIB, but the APF list of 
> > libraries, should be protected, since that is one way someone can get into 
> > the OS.
> > Provided the person has access to one of those libraries.  So, I 
> > tended
> to
> > be, maybe, over protective of the APF and possible LNKLST, depending 
> > upon the system parms.
> >
> >
> > Jerry Edgington  |  Sr.Technical Analyst IT Technical Operations 
> > Enterprise Systems
> > 400 Broadway  |  Cincinnati, Ohio 45202
> > 513.629.1826 direct
> > 513.629.1787 fax
> > WesternSouthern.com
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Ed Jaffe
> > Sent: Friday, February 4, 2022 12:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS 
> > PARMLIB's?
> >
> > This message was sent from an external source outside of Western & 
> > Southern's network. Do not click links or open attachments unless 
> > you recognize the sender and know the contents are safe.
> >
> >
> __
> __
> >
> > On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> > > I see the rule but I do not understand the rationale.  Limiting 
> > > UPDATE
> > and ALTER access to systems programmers is logical and reasonable.
> > Limiting READ access is not unless there are parameters in PARMLIB 
> > not available anywhere else that can be used to gain an elevation of
> authority.
> >
> > The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB 
> > since all of our specifications are in SYS2.PARMLIB! LOL
> >
> > Considering PARMLIB in general, there used to be some passwords in 
> > the clear that would appear there (e.g., NJE). I have no idea if 
> > that's still true today.
> >
> > FWIW, there is absolutely nothing in our PARMLIB that we try to hide 
> > from end users. We might be naive...
> >
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > https://www.phoenixsoftware.com/
> >
> >
> >
> >
> --
> --
> > This e-mail message, including any attachments, appended messages 
> > and the information contained therein, is for the 

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Charles Mills]

There are two conflicting pieces of general advice that are applicable here.

A. Making PARMLIB inaccessible is security by obscurity. You are not securing 
the APF libraries by making one list of them unreadable.

B. Multiple lines of defense. Sure, there are other ways to get things like a 
list of APF libraries, but why not make it as hard as possible? Maybe your 
attacker is pretty ignorant of z/OS: he knows about SYS1.PARMLIB but does not 
know about SHOWZOS or how to use Rexx STORAGE.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of ITschak Mugzach
Sent: Friday, February 4, 2022 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

Only few of the parmlib members are represented on mobs control blocks.
Attacker may want to understand how smf is configured, to make sure his
activity is not recorded, what are the dump dataset mask, racf dataset
table (if it is a racf shop) and and many other information that help
penetrate the system.

Remember the first rule of security “need to know”. Most users do not have
the need. And for the hacker: You want the data, sweat!

ITschak

בתאריך יום ו׳, 4 בפבר׳ 2022 ב-20:25 מאת Mike Shaw :

> Amen Lionel. SHOWZOS is publicly available. Users can write their own REXX
> code using the STORAGE function to display the active APF list on their
> system. Security through (attempted) obscurity does not work.
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
>
> On Fri, Feb 4, 2022 at 1:02 PM Lionel B. Dyck  wrote:
>
> > If you want to hide your APF list then you also need to prevent ISRDDN's
> > APF option as it displays the APF list very nicely. I'm sure you can
> > protect the SDSF APF command, but can you prevent SHOWZOS, and other
> tools,
> > from looking in storage and displaying the list for you?  The fact is
> that
> > you can't.
> >
> > Perhaps you should, if following the STIG rules for PARMLIB, also prevent
> > user access to /etc in your OMVS and other *nix environments.
> >
> > Lionel B. Dyck <><
> > Website: https://www.lbdsoftware.com
> > Github: https://github.com/lbdyck
> >
> > “Worry more about your character than your reputation. Character is what
> > you are, reputation merely what others think you are.”   - - - John
> Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Edgington, Jerry
> > Sent: Friday, February 4, 2022 11:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS
> > PARMLIB's?
> >
> > I agree with Ed, for most of the PARMLIB, but the APF list of libraries,
> > should be protected, since that is one way someone can get into the OS.
> > Provided the person has access to one of those libraries.  So, I tended
> to
> > be, maybe, over protective of the APF and possible LNKLST, depending upon
> > the system parms.
> >
> >
> > Jerry Edgington  |  Sr.Technical Analyst IT Technical Operations
> > Enterprise Systems
> > 400 Broadway  |  Cincinnati, Ohio 45202
> > 513.629.1826 direct
> > 513.629.1787 fax
> > WesternSouthern.com
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Ed Jaffe
> > Sent: Friday, February 4, 2022 12:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS
> > PARMLIB's?
> >
> > This message was sent from an external source outside of Western &
> > Southern's network. Do not click links or open attachments unless you
> > recognize the sender and know the contents are safe.
> >
> >
> 
> >
> > On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> > > I see the rule but I do not understand the rationale.  Limiting UPDATE
> > and ALTER access to systems programmers is logical and reasonable.
> > Limiting READ access is not unless there are parameters in PARMLIB not
> > available anywhere else that can be used to gain an elevation of
> authority.
> >
> > The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB since
> > all of our specifications are in SYS2.PARMLIB! LOL
> >
> > Considering PARMLIB in general, there used to be some passwords in the
> > clear that would appear there (e.g., NJE). I have no idea if that's still
> > true today.
> >
> > FWIW, there is absolutely nothing in our PARMLIB that we try to hide from
> > end users. We might be naive...
> >
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > https://www.phoenixsoftware.com/
> >
> >
> >
> >
> 
> > This e-mail message, including any attachments, appended messages and the
> > information contained therein, is for the sole use of the 

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[ITschak Mugzach]

Only few of the parmlib members are represented on mobs control blocks.
Attacker may want to understand how smf is configured, to make sure his
activity is not recorded, what are the dump dataset mask, racf dataset
table (if it is a racf shop) and and many other information that help
penetrate the system.

Remember the first rule of security “need to know”. Most users do not have
the need. And for the hacker: You want the data, sweat!

ITschak

בתאריך יום ו׳, 4 בפבר׳ 2022 ב-20:25 מאת Mike Shaw :

> Amen Lionel. SHOWZOS is publicly available. Users can write their own REXX
> code using the STORAGE function to display the active APF list on their
> system. Security through (attempted) obscurity does not work.
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
>
> On Fri, Feb 4, 2022 at 1:02 PM Lionel B. Dyck  wrote:
>
> > If you want to hide your APF list then you also need to prevent ISRDDN's
> > APF option as it displays the APF list very nicely. I'm sure you can
> > protect the SDSF APF command, but can you prevent SHOWZOS, and other
> tools,
> > from looking in storage and displaying the list for you?  The fact is
> that
> > you can't.
> >
> > Perhaps you should, if following the STIG rules for PARMLIB, also prevent
> > user access to /etc in your OMVS and other *nix environments.
> >
> > Lionel B. Dyck <><
> > Website: https://www.lbdsoftware.com
> > Github: https://github.com/lbdyck
> >
> > “Worry more about your character than your reputation. Character is what
> > you are, reputation merely what others think you are.”   - - - John
> Wooden
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Edgington, Jerry
> > Sent: Friday, February 4, 2022 11:47 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS
> > PARMLIB's?
> >
> > I agree with Ed, for most of the PARMLIB, but the APF list of libraries,
> > should be protected, since that is one way someone can get into the OS.
> > Provided the person has access to one of those libraries.  So, I tended
> to
> > be, maybe, over protective of the APF and possible LNKLST, depending upon
> > the system parms.
> >
> >
> > Jerry Edgington  |  Sr.Technical Analyst IT Technical Operations
> > Enterprise Systems
> > 400 Broadway  |  Cincinnati, Ohio 45202
> > 513.629.1826 direct
> > 513.629.1787 fax
> > WesternSouthern.com
> >
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Ed Jaffe
> > Sent: Friday, February 4, 2022 12:43 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: What is the audit basis to prevent read access to z/OS
> > PARMLIB's?
> >
> > This message was sent from an external source outside of Western &
> > Southern's network. Do not click links or open attachments unless you
> > recognize the sender and know the contents are safe.
> >
> >
> 
> >
> > On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> > > I see the rule but I do not understand the rationale.  Limiting UPDATE
> > and ALTER access to systems programmers is logical and reasonable.
> > Limiting READ access is not unless there are parameters in PARMLIB not
> > available anywhere else that can be used to gain an elevation of
> authority.
> >
> > The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB since
> > all of our specifications are in SYS2.PARMLIB! LOL
> >
> > Considering PARMLIB in general, there used to be some passwords in the
> > clear that would appear there (e.g., NJE). I have no idea if that's still
> > true today.
> >
> > FWIW, there is absolutely nothing in our PARMLIB that we try to hide from
> > end users. We might be naive...
> >
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> > https://www.phoenixsoftware.com/
> >
> >
> >
> >
> 
> > This e-mail message, including any attachments, appended messages and the
> > information contained therein, is for the sole use of the intended
> > recipient(s). If you are not an intended recipient or have otherwise
> > received this email message in error, any use, dissemination,
> distribution,
> > review, storage or copying of this e-mail message and the information
> > contained therein is strictly prohibited. If you are not an intended
> > recipient, please contact the sender by reply e-mail and destroy all
> copies
> > of this email message and do not otherwise utilize or retain this email
> > message or any or all of the information contained therein. Although this
> > email message and any attachments or appended messages are believed to be
> > free of any virus or other defect that might affect any computer system
> > into
> > which it is received and opened, it is the responsibility of the
> 

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Mike Shaw]

Amen Lionel. SHOWZOS is publicly available. Users can write their own REXX
code using the STORAGE function to display the active APF list on their
system. Security through (attempted) obscurity does not work.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.


On Fri, Feb 4, 2022 at 1:02 PM Lionel B. Dyck  wrote:

> If you want to hide your APF list then you also need to prevent ISRDDN's
> APF option as it displays the APF list very nicely. I'm sure you can
> protect the SDSF APF command, but can you prevent SHOWZOS, and other tools,
> from looking in storage and displaying the list for you?  The fact is that
> you can't.
>
> Perhaps you should, if following the STIG rules for PARMLIB, also prevent
> user access to /etc in your OMVS and other *nix environments.
>
> Lionel B. Dyck <><
> Website: https://www.lbdsoftware.com
> Github: https://github.com/lbdyck
>
> “Worry more about your character than your reputation. Character is what
> you are, reputation merely what others think you are.”   - - - John Wooden
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Edgington, Jerry
> Sent: Friday, February 4, 2022 11:47 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the audit basis to prevent read access to z/OS
> PARMLIB's?
>
> I agree with Ed, for most of the PARMLIB, but the APF list of libraries,
> should be protected, since that is one way someone can get into the OS.
> Provided the person has access to one of those libraries.  So, I tended to
> be, maybe, over protective of the APF and possible LNKLST, depending upon
> the system parms.
>
>
> Jerry Edgington  |  Sr.Technical Analyst IT Technical Operations
> Enterprise Systems
> 400 Broadway  |  Cincinnati, Ohio 45202
> 513.629.1826 direct
> 513.629.1787 fax
> WesternSouthern.com
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Ed Jaffe
> Sent: Friday, February 4, 2022 12:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the audit basis to prevent read access to z/OS
> PARMLIB's?
>
> This message was sent from an external source outside of Western &
> Southern's network. Do not click links or open attachments unless you
> recognize the sender and know the contents are safe.
>
> 
>
> On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> > I see the rule but I do not understand the rationale.  Limiting UPDATE
> and ALTER access to systems programmers is logical and reasonable.
> Limiting READ access is not unless there are parameters in PARMLIB not
> available anywhere else that can be used to gain an elevation of authority.
>
> The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB since
> all of our specifications are in SYS2.PARMLIB! LOL
>
> Considering PARMLIB in general, there used to be some passwords in the
> clear that would appear there (e.g., NJE). I have no idea if that's still
> true today.
>
> FWIW, there is absolutely nothing in our PARMLIB that we try to hide from
> end users. We might be naive...
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://www.phoenixsoftware.com/
>
>
>
> 
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s). If you are not an intended recipient or have otherwise
> received this email message in error, any use, dissemination, distribution,
> review, storage or copying of this e-mail message and the information
> contained therein is strictly prohibited. If you are not an intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of this email message and do not otherwise utilize or retain this email
> message or any or all of the information contained therein. Although this
> email message and any attachments or appended messages are believed to be
> free of any virus or other defect that might affect any computer system
> into
> which it is received and opened, it is the responsibility of the recipient
> to ensure that it is virus free and no responsibility is accepted by the
> sender for any loss or damage arising in any way from its opening or use.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> 

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Lionel B. Dyck]

If you want to hide your APF list then you also need to prevent ISRDDN's APF 
option as it displays the APF list very nicely. I'm sure you can protect the 
SDSF APF command, but can you prevent SHOWZOS, and other tools, from looking in 
storage and displaying the list for you?  The fact is that you can't.

Perhaps you should, if following the STIG rules for PARMLIB, also prevent user 
access to /etc in your OMVS and other *nix environments.

Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Edgington, Jerry
Sent: Friday, February 4, 2022 11:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

I agree with Ed, for most of the PARMLIB, but the APF list of libraries, should 
be protected, since that is one way someone can get into the OS.  Provided the 
person has access to one of those libraries.  So, I tended to be, maybe, over 
protective of the APF and possible LNKLST, depending upon the system parms.


Jerry Edgington  |  Sr.Technical Analyst IT Technical Operations Enterprise 
Systems
400 Broadway  |  Cincinnati, Ohio 45202
513.629.1826 direct
513.629.1787 fax
WesternSouthern.com



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Friday, February 4, 2022 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> I see the rule but I do not understand the rationale.  Limiting UPDATE and 
> ALTER access to systems programmers is logical and reasonable.  Limiting READ 
> access is not unless there are parameters in PARMLIB not available anywhere 
> else that can be used to gain an elevation of authority.

The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB since all 
of our specifications are in SYS2.PARMLIB! LOL

Considering PARMLIB in general, there used to be some passwords in the clear 
that would appear there (e.g., NJE). I have no idea if that's still true today.

FWIW, there is absolutely nothing in our PARMLIB that we try to hide from end 
users. We might be naive...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Edgington, Jerry]

I agree with Ed, for most of the PARMLIB, but the APF list of libraries, should 
be protected, since that is one way someone can get into the OS.  Provided the 
person has access to one of those libraries.  So, I tended to be, maybe, over 
protective of the APF and possible LNKLST, depending upon the system parms.


Jerry Edgington  |  Sr.Technical Analyst
IT Technical Operations
Enterprise Systems
400 Broadway  |  Cincinnati, Ohio 45202
513.629.1826 direct 
513.629.1787 fax 
WesternSouthern.com



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Friday, February 4, 2022 12:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:
> I see the rule but I do not understand the rationale.  Limiting UPDATE and 
> ALTER access to systems programmers is logical and reasonable.  Limiting READ 
> access is not unless there are parameters in PARMLIB not available anywhere 
> else that can be used to gain an elevation of authority.

The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB since all 
of our specifications are in SYS2.PARMLIB! LOL

Considering PARMLIB in general, there used to be some passwords in the clear 
that would appear there (e.g., NJE). I have no idea if that's still true today.

FWIW, there is absolutely nothing in our PARMLIB that we try to hide from end 
users. We might be naive...


-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Ed Jaffe]

On 2/4/2022 7:04 AM, Farley, Peter x23353 wrote:

I see the rule but I do not understand the rationale.  Limiting UPDATE and 
ALTER access to systems programmers is logical and reasonable.  Limiting READ 
access is not unless there are parameters in PARMLIB not available anywhere 
else that can be used to gain an elevation of authority.


The z/OS STIG is often wrong. I laugh when it protects SYS1.PARMLIB 
since all of our specifications are in SYS2.PARMLIB! LOL


Considering PARMLIB in general, there used to be some passwords in the 
clear that would appear there (e.g., NJE). I have no idea if that's 
still true today.


FWIW, there is absolutely nothing in our PARMLIB that we try to hide 
from end users. We might be naive...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Tom Brennan]

That's what I was thinking.  Hiding parmlib puts a rock in the road, but 
you can just walk around it.


A long time ago I remember trying to compress parmlib in place and found 
a started task had it allocated in its JCL.  I can't remember why that 
was - I assume to read bits and pieces at various times.  So maybe 
there's a legitimate reason for at least that one task to read parmlib.


On 2/3/2022 11:56 PM, Bruce Hewson wrote:

Hi Peter,

1. Seems auditors want security by hiding stuff
2. Access to PARMLIB means that someone can see what datasets can be APF 
Authorized.
3. Access to PARMLIB means that someone can see what SVC could be loaded.

not sure why else.

and there are other ways to find the above information  if I already logged in 
to TSO or OMVS to be able to read the PARMLIB datasets.

Regards
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Lennie Dymoke-Bradshaw]

While the status of the active settings derived from Parmlib members may be 
viewable using tools such as IPLINFO and the like, there are other things in 
Parmlibs as well.

For example, 
1. many sites will have Parmlib shared amongst members of a sysplex. So READ 
access to Parmlib gives you those settings as well. If you don't have the 
ability to logon to those systems you can still get some of their settings.
2. Many sites keep fallback settings or recovery setting in Parmlib. It is 
possible these may have lower security (in order to accommodate recovery). So 
read access gives you those as well.
3. The names of people involved in making settings changes are often recorded 
in Parmlib in comments. Using these names can be an opportunity for social 
engineering of help desk staff.

Above all, turn the question round. Why do users *need* access to Parmlib? If 
they can manage without read access and still do their jobs efficiently why 
give them (and others) access? Most development TSO users will not need access. 
Many support staff will need access. Set the access accordingly. Use the 
principle of least access to grant access where needed, rather than denying 
where needed.

Think further. Think like a hacker.
Lennie

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Radoslaw Skorupka
Sent: 04 February 2022 11:42
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

W dniu 04.02.2022 o 00:12, Farley, Peter x23353 pisze:
> I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
> to be dangerous, BUT . . .
>
> What information could possibly be gleaned from reading PARMLIB that would 
> require a knowledgeable auditor to insist on restricting read access (other 
> than security by obscurity and sysprog/auditor job security)?
>
> Just curious, I don't plan on hacking anything.

Official IBM documentations says the proper security setting for PARMLIB is 
READ.
This is good answer to any auditor.
(Exceptions like open-text passwords should be moved to separate dataset, but 
definitely avoided)

IBM's clarification: the information in PARMLIB is accessible to any 
non-privileged user via control blocks, CVT, etc.

My humble opinion: security by obscurity is no security. Educated hacked (or 
currently trendy "threat actor") will get relevant information without readind 
PARMLIB. Uneducated hacker... Stop! If you afraid of uneducated hackers then 
you quickly need to fix something.
My €0,02

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Itschak Mugzach]

When it comes to security, a "need to know" rule applies. This Is true that
some (but not all, even not most, of the parmlib is in MVS control blocks.
However, as a pen tester, I want to know which SMF records are recording my
activity, dataset name of os components that are not part of their mvs
lists (apf,linklist, etc). If you want to perform an attack, you need to
find your attack vector and it takes time to discover what you need. I
think that this process is called "readiness review" by intent...

ITschak

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Fri, Feb 4, 2022 at 5:31 PM René Jansen 
wrote:

> Several companies I was at lately had this policy of no read access to
> PARMLIB, and it is a pain because things you are used to, like IPCS, do not
> work without RACF READ access to it. I seem to remember that other tools
> also get their startup parms from PARMLIB, so that seems very
> counterproductive.
>
> René.
>
> > On 4 Feb 2022, at 16:26, Seymour J Metz  wrote:
> >
> > I don't believe that read access to PARMLIB is a security risk, and it
> is possible that a prohibition could actually lead to security issues, but
> if you are under the pervue of DISA the you need to abide by their
> policies, although I would probably document the fact that I considered
> UACC=NONE for PARMLIB inappropriate.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Farley, Peter x23353 [
> 031df298a9da-dmarc-requ...@listserv.ua.edu]
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[René Jansen]

Several companies I was at lately had this policy of no read access to PARMLIB, 
and it is a pain because things you are used to, like IPCS, do not work without 
RACF READ access to it. I seem to remember that other tools also get their 
startup parms from PARMLIB, so that seems very counterproductive.

René.

> On 4 Feb 2022, at 16:26, Seymour J Metz  wrote:
> 
> I don't believe that read access to PARMLIB is a security risk, and it is 
> possible that a prohibition could actually lead to security issues, but if 
> you are under the pervue of DISA the you need to abide by their policies, 
> although I would probably document the fact that I considered UACC=NONE for 
> PARMLIB inappropriate.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Seymour J Metz]

I don't believe that read access to PARMLIB is a security risk, and it is 
possible that a prohibition could actually lead to security issues, but if you 
are under the pervue of DISA the you need to abide by their policies, although 
I would probably document the fact that I considered UACC=NONE for PARMLIB 
inappropriate.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Farley, Peter x23353 [031df298a9da-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, February 3, 2022 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

That was my question -- what possible attack vector can be derived form PARMLIB 
entries?  I cannot see any such vector coming out of anything I know about 
PARMLIB, but I probably don’t know enough, which is why I am asking here.

No passwords, no information that Mark Zelden's IPLINFO can’t retrieve anyway 
from a running system, so what's the issue?

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Thursday, February 3, 2022 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

I would suspect that it exposes potential attack vectors for the system.  
Ideally the system should be secure but loose lips sink ships.

Matt Hogstrom
m...@hogstrom.org

“To my Ph.D. supervisor, for whom no thanks is too much.”

> On Feb 3, 2022, at 6:12 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
>
> I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
> to be dangerous, BUT . . .
>
> What information could possibly be gleaned from reading PARMLIB that would 
> require a knowledgeable auditor to insist on restricting read access (other 
> than security by obscurity and sysprog/auditor job security)?
>
> Just curious, I don't plan on hacking anything.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Farley, Peter x23353]

I see the rule but I do not understand the rationale.  Limiting UPDATE and 
ALTER access to systems programmers is logical and reasonable.  Limiting READ 
access is not unless there are parameters in PARMLIB not available anywhere 
else that can be used to gain an elevation of authority.

I have not yet seen any answer that lists or categorizes any such parameters.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Friday, February 4, 2022 2:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

Hi Peter,

Follow the rule of the attached STIG:

SYS1.PARMLIB is not limited to only system programmers.

z/OS RACF STIG 




On Fri, Feb 4, 2022 at 1:51 AM Farley, Peter x23353 < 
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> That was my question -- what possible attack vector can be derived 
> form PARMLIB entries?  I cannot see any such vector coming out of 
> anything I know about PARMLIB, but I probably don’t know enough, which 
> is why I am asking here.
>
> No passwords, no information that Mark Zelden's IPLINFO can’t retrieve 
> anyway from a running system, so what's the issue?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Matt Hogstrom
> Sent: Thursday, February 3, 2022 6:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the audit basis to prevent read access to z/OS 
> PARMLIB's?
>
> I would suspect that it exposes potential attack vectors for the system.
> Ideally the system should be secure but loose lips sink ships.
>
> Matt Hogstrom
> m...@hogstrom.org
>
> “To my Ph.D. supervisor, for whom no thanks is too much.”
>
> > On Feb 3, 2022, at 6:12 PM, Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > I'll be the first to admit that I know just enough of what is in
> SYS1.PARMLIB to be dangerous, BUT . . .
> >
> > What information could possibly be gleaned from reading PARMLIB that
> would require a knowledgeable auditor to insist on restricting read 
> access (other than security by obscurity and sysprog/auditor job security)?
> >
> > Just curious, I don't plan on hacking anything.
-- 


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Radoslaw Skorupka]

W dniu 04.02.2022 o 00:12, Farley, Peter x23353 pisze:

I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
to be dangerous, BUT . . .

What information could possibly be gleaned from reading PARMLIB that would 
require a knowledgeable auditor to insist on restricting read access (other 
than security by obscurity and sysprog/auditor job security)?

Just curious, I don't plan on hacking anything.


Official IBM documentations says the proper security setting for PARMLIB 
is READ.

This is good answer to any auditor.
(Exceptions like open-text passwords should be moved to separate 
dataset, but definitely avoided)


IBM's clarification: the information in PARMLIB is accessible to any 
non-privileged user via control blocks, CVT, etc.


My humble opinion: security by obscurity is no security. Educated hacked 
(or currently trendy "threat actor") will get relevant information 
without readind PARMLIB. Uneducated hacker... Stop! If you afraid of 
uneducated hackers then you quickly need to fix something.

My €0,02

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Bruce Hewson]

Hi Peter,

1. Seems auditors want security by hiding stuff
2. Access to PARMLIB means that someone can see what datasets can be APF 
Authorized.
3. Access to PARMLIB means that someone can see what SVC could be loaded.

not sure why else.

and there are other ways to find the above information  if I already logged in 
to TSO or OMVS to be able to read the PARMLIB datasets.

Regards
Bruce

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Itschak Mugzach]

Hi Peter,

Follow the rule of the attached STIG:

SYS1.PARMLIB is not limited to only system programmers.

Overview
Finding IDVersionRule IDIA ControlsSeverity
V-108 ACP00010 SV-108r2_rule DCCS-1
DCCS-2
DCSL-1
ECAR-1
ECAR-2
ECAR-3
 High
Description
SYS1.PARMLIB contains the parameters which control system IPL,
configuration characteristics, security facilities, and performance.
Unauthorized access could result in the compromise of the operating system
environment, ACP, and customer data.
STIGDate
z/OS RACF STIG 
2019-12-12
Details
Check Text ( C-676r1_chk )
a) Refer to the following report produced by the Data Set and Resource Data
Collection:

- SENSITVE.RPT(PARMRPT)

Automated Analysis
Refer to the following report produced by the Data Set and Resource Data
Collection:

- PDI(ACP00010)

___ The ACP data set rules for SYS1.PARMLIB allow inappropriate (e.g.,
global READ) access.

___ The ACP data set rules for SYS1.PARMLIB do not restrict READ, UPDATE
and ALTER access to only systems programming personnel.

___ The ACP data set rules for SYS1.PARMLIB do not restrict READ and UPDATE
access to only domain level security administrators.

___ The ACP data set rules for SYS1.PARMLIB do not restrict READ access to
only system Level Started Tasks, authorized Data Center personnel, and
auditors.

___ The ACP data set rules for SYS1.PARMLIB do not specify that all (i.e.,
failures and successes) UPDATE and/or ALTER access will be logged.

b) If all of the above are untrue, there is NO FINDING.

c) If any of the above is true, this is a FINDING.
Fix Text (F-25790r1_fix)
The IAO will ensure that update and alter access to SYS1.PARMLIB is limited
to system programmers only and all update and alter access is logged.

Review access authorization to critical system files. Evaluate the impact
of correcting the deficiency. Develop a plan of action and implement the
changes as required

The IAO will implement controls to specify the valid users authorized to
update the SYS1.PARMLIB concatenation. All update and alter access to
libraries in the concatenation will be logged using the ACP's facilities.

1. That systems programming personnel will be authorized to update and
alter the SYS1.PARMLIB concatenation.
2. That domain level security administrators can be authorized to update
the SYS1.PARMLIB concatenation.
3. That System Level Started Tasks, authorized Data Center personnel, and
auditor can be authorized read access by the IAO.
4. That all update and alter access is logged.

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **|  *

*|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il  **|*





On Fri, Feb 4, 2022 at 1:51 AM Farley, Peter x23353 <
031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:

> That was my question -- what possible attack vector can be derived form
> PARMLIB entries?  I cannot see any such vector coming out of anything I
> know about PARMLIB, but I probably don’t know enough, which is why I am
> asking here.
>
> No passwords, no information that Mark Zelden's IPLINFO can’t retrieve
> anyway from a running system, so what's the issue?
>
> Peter
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Matt Hogstrom
> Sent: Thursday, February 3, 2022 6:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What is the audit basis to prevent read access to z/OS
> PARMLIB's?
>
> I would suspect that it exposes potential attack vectors for the system.
> Ideally the system should be secure but loose lips sink ships.
>
> Matt Hogstrom
> m...@hogstrom.org
>
> “To my Ph.D. supervisor, for whom no thanks is too much.”
>
> > On Feb 3, 2022, at 6:12 PM, Farley, Peter x23353 <
> 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > I'll be the first to admit that I know just enough of what is in
> SYS1.PARMLIB to be dangerous, BUT . . .
> >
> > What information could possibly be gleaned from reading PARMLIB that
> would require a knowledgeable auditor to insist on restricting read access
> (other than security by obscurity and sysprog/auditor job security)?
> >
> > Just curious, I don't plan on hacking anything.
> --
>
>
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this 

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Farley, Peter x23353]

That was my question -- what possible attack vector can be derived form PARMLIB 
entries?  I cannot see any such vector coming out of anything I know about 
PARMLIB, but I probably don’t know enough, which is why I am asking here.

No passwords, no information that Mark Zelden's IPLINFO can’t retrieve anyway 
from a running system, so what's the issue?

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matt Hogstrom
Sent: Thursday, February 3, 2022 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

I would suspect that it exposes potential attack vectors for the system.  
Ideally the system should be secure but loose lips sink ships.

Matt Hogstrom
m...@hogstrom.org

“To my Ph.D. supervisor, for whom no thanks is too much.”

> On Feb 3, 2022, at 6:12 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
> to be dangerous, BUT . . .
> 
> What information could possibly be gleaned from reading PARMLIB that would 
> require a knowledgeable auditor to insist on restricting read access (other 
> than security by obscurity and sysprog/auditor job security)?
> 
> Just curious, I don't plan on hacking anything.
-- 


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Paul Gilmartin]

On Thu, 3 Feb 2022 23:12:10 +, Farley, Peter x23353 wrote:

>I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
>to be dangerous, BUT . . .
>
>What information could possibly be gleaned from reading PARMLIB that would 
>require a knowledgeable auditor to insist on restricting read access (other 
>than security by obscurity and sysprog/auditor job security)?
>
>Just curious, I don't plan on hacking anything.
> 
https://en.wikipedia.org/wiki/Totalitarian_principle

It spares the sysprog/auditor the burden of proving, axiomatically,
that it's safe.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: What is the audit basis to prevent read access to z/OS PARMLIB's?

[Matt Hogstrom]

I would suspect that it exposes potential attack vectors for the system.  
Ideally the system should be secure but loose lips sink ships.

Matt Hogstrom
m...@hogstrom.org

“To my Ph.D. supervisor, for whom no thanks is too much.”

> On Feb 3, 2022, at 6:12 PM, Farley, Peter x23353 
> <031df298a9da-dmarc-requ...@listserv.ua.edu> wrote:
> 
> I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
> to be dangerous, BUT . . .
> 
> What information could possibly be gleaned from reading PARMLIB that would 
> require a knowledgeable auditor to insist on restricting read access (other 
> than security by obscurity and sysprog/auditor job security)?
> 
> Just curious, I don't plan on hacking anything.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

What is the audit basis to prevent read access to z/OS PARMLIB's?

[Farley, Peter x23353]

I'll be the first to admit that I know just enough of what is in SYS1.PARMLIB 
to be dangerous, BUT . . .

What information could possibly be gleaned from reading PARMLIB that would 
require a knowledgeable auditor to insist on restricting read access (other 
than security by obscurity and sysprog/auditor job security)?

Just curious, I don't plan on hacking anything.

Peter
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN