[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: APF library - UACC(R)
From:       ITschak Mugzach <imugzach () GMAIL ! COM>
Date:       2021-10-01 9:42:10
Message-ID: CAOdPEgR85j3weAJZ-2F1CUoig4=vWkE=wPatusV_17bSGt7tbg () mail ! gmail ! com
[Download RAW message or body]

Bogdan,

See
https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-security-system-data-sets
Tbale-1. APG datasets should have UACC(NONE).

Best,
ITschak

ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Fri, Oct 1, 2021 at 12:06 PM Bogdan Belciu <bogdan.belciu.i@gmail.com>
wrote:

> Hi,
>
> I am not sure, we have auditing jobs on a customer that check exactly
> this.. they were set up some years ago, not sure by whom.
> If someone designed some jobs to check this then they must have
> followed some standard..
>
> APF libs should have individual dataset profiles in RACF.
> On the profiles, if the UACC is READ or * READ in ACL  then AUDIT should be
> at least success updates failures read.
> But they make sense to me.
>
> On Fri, 1 Oct 2021 at 00:39, Radoslaw Skorupka <R.Skorupka@hotmail.com>
> wrote:
>
> > What audit standard says so?
> > Can you provide a link?
> >
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> > W dniu 28.09.2021 o 16:12, Bogdan Belciu pisze:
> > > Hi,
> > >
> > > an audit standard requires that if you have UACC(READ) in an APF-ed
> > library
> > > then the profile must be specific (never use *%) so the name of the
> RACF
> > > profile should match the dataset name and also to have the audit
> minimum
> > > S(U) F(R).
> > > There are cases when some APDed datasets like DB2 loadlib libraries
> need
> > to
> > > be read by anyone, so UACC READ is justified.
> > >
> > > On Tue, 28 Sept 2021 at 16:37, Mautalen Juan Guillermo <
> > > jmautalen@anses.gov.ar> wrote:
> > >
> > >> Hi! I have a question regarding protection of an APF authorized CICS
> > >> library. The "CICS RACF Security Guide" says:
> > >>
> > >> <<
> > >> However, you must strictly control who has read access
> > >> to CICSTS53.CICS.SDFHAUTH, because it contains APF-authorized
> programs,
> > and
> > >> the profile protecting this data set must be defined with UACC(NONE).
> > >> We all know the requirement to STRICTLY control who can UPDATE an APF
> > >> library. But, in general, it is my understanding that READ authority
> > over
> > >> an APF authorized library is not a security exposure, as it basically
> > only
> > >> allows execution of those programs (that we trust to behave correctly
> > and
> > >> have their proper security controls, when necessary).
> > >>
> > >> Am I missing something?
> > >> Has this particular CICS LOAD library any characteristic that makes it
> > >> specially risky to protect it with UACC(READ)?
> > >>
> > >> And, as a broader question, do you see any security exposure in
> > protecting
> > >> APF libraries with UACC(READ)? I am talking here about IBM supplied
> APF
> > >> libraries (or by a well known vendor).
> > >>
> > >> Thanks in advance for your help,
> > >>
> > >> Juan G. Mautalen
> > >>
> > >> El contenido del presente mensaje y sus anexos es privado,
> confidencial
> > y
> > >> de exclusivo uso para el destinatario referenciado. Puede contener
> > >> informacion privilegiada o amparada por el secreto profesional o por
> > >> disposiciones legales y/o reglamentarias vigentes. Cualquier
> > modificacion,
> > >> retransmision, diseminacion o divulgacion de su informacion se
> encuentra
> > >> expresamente prohibida y su uso inadecuado puede derivar en
> > responsabilidad
> > >> civil para el usuario o configurar los delitos previstos en los
> > articulos
> > >> 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios
> > >> consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a
> > >> utilizar total o parcialmente, copiar, enviar, revelar, imprimir,
> > divulgar
> > >> de manera alguna el contenido del presente mensaje o el de sus
> > adjuntos. En
> > >> consecuencia, tenga a bien comunicarselo inmediatamente al emisor y
> > >> ELIMINARLO. ANSES no garantiza la seguridad, integridad, exactitud u
> > >> oportunidad de lo transmitido por este medio ni se responsabiliza de
> > >> posibles perjuicios derivados de la captura, incorporaciones de virus
> o
> > >> cualquier otra manipulación efectuada por terceros. Asimismo, las
> > opiniones
> > >> expresadas en este mensaje y en los archivos adjuntos son propias del
> > >> remitente y no representan la opinion o politicas de ANSES, salvo que
> se
> > >> diga expresamente y el remitente se encuentre  autorizado para ello.
> Por
> > >> ende, ANSES no asumira -en ningun caso- responsabilidad alguna frente
> al
> > >> destinatario y/o terceros en virtud de dichas comunicaciones y ademas,
> > no
> > >> sera responsable frente a los usuarios por la correspondencia o los
> > >> mensajes de correo electronico enviados por terceros u otras personas
> > >> distintas a ANSES, ya sea que estos hubieren o no solicitado el envio
> de
> > >> tales mensajes. ANSES se reserva el derecho de bloquear el acceso o
> > remover
> > >> en forma parcial o total todo mensaje y sus adjuntos que a su criterio
> > >> pudiere resultar abusivo, difamatorio, obsceno, fraudulento,
> > artificioso,
> > >> engañoso, ofensivo o violatorio a los terminos de la presente.  PD:
> > Tildes
> > >> omitidas intencionalmente.
> > >>
> >
>
[prev in list] [next in list] [prev in thread] [next in thread]