SYSLIBL -- Protecting Libraries on the System Library List

SYSLIBL PROTECTING LIBRARIES ON SYSLIBL TAAAUDB
The System Library List tool is a documentation member only to help understand the basics of how to control and audit the changes to libraries on the system library list. TAA Tools that can assist are also mentioned. Why is controlling the system library list libraries important -------------------------------------------------------------- The libraries on the system library list become part of every job. While the list of libraries can be changed, it normally includes QSYS which contains most of the system functions. It is possible to place a program or command that has the same name as a system name in a library in front of QSYS and gain control when a user thinks he is executing a system function. This document discusses how to review what is currently being used and how to control and audit changes. The system library list ----------------------- The system library list is determined by the QSYSLIBL system value. You can display the value with: DSPSYSVAL SYSVAL(QSYSLIBL) The shipped values are QSYS, QSYS2, QHLPSYS, and QUSRSYS. QSYS contains many object types including commands and programs. QSYS2 contains programs and other object types, but not commands. It is generally a good idea to keep track of what you have specified so you can compare to the current values. The TAA Tool CAPSECINF will do this for system values as well as user profiles, network attributes, and registration information. See the tool discussion for how to set it up. You can use up a job scheduling job to capture the information periodically. You can then compare any two periods to see what has changed. CHGSYSLIBL Command ------------------ The system provided CHGSYSLIBL command allows the system library list to be changed for the current job (only the job executing the command would be affected). You should review who is authorized to CHGSYSLIBL with: DSPOBJAUT OBJ(CHGSYSLIBL) OBJTYPE(CMD) The command is shipped as PUBLIC EXCLUDE. You would have to have a very specific reason to allow the PUBLIC any other usage. If you have users that are authorized to use CHGSYSLIBL, you should ensure you have done so with a specific reason in mind. In general, there are now many other solutions to allow the tailoring of a job besides CHGSYSLIBL. Using CHGSYSLIBL increases the security risk. While you may not have any users authorized to CHGSYSLIBL, you cannot prevent an ALLOBJ user from using the command. While you cannot prevent the use, you can audit the fact that it occurred. See the later section on Auditing. Placing a user library in front of QSYS --------------------------------------- Some users want to place a user library in front of QSYS so they can change what certain commands do. This can be effective for some functions, but increases the security exposure that system functions can be mis-used. As of V5R4, the system supports the capability for a command exit which is a safer method of changing the action of a command. See the TAA Tool CMDEXIT for how to write a command exit. Neither approach will work if the user of a command you are trying to change uses a qualified name such as QSYS/xxx. If you want to audit that a command has been used, the system auditing function is a better function than attempting to use a command exit. If you have such a library, it is a good idea to track what exists and compare it the previous information. The TAA Tool CMPLIB2 can do this. You need the CAPLIB2 command to capture the information (it creates an outfile). When you want to make a comparison, you use CAPLIB2 again and output the outfile to a different library. Then use the CMPLIB2 command to compare the two sets of values. You could also use the same technique for the QSYS and QSYS2 libraries. Authorizations to system library list libraries ----------------------------------------------- You should review the authorizations to the libraries that make up the library list. For each library on the system library list check the authorizations such as QSYS with: DSPOBJAUT OBJ(QSYS) OBJTYPE(LIB) The system libraries like QSYS are shipped as PUBLIC USE. Unless you have some specific reason, the system libraries are best left as PUBLIC USE. If you have a user library in front of QSYS, you want to be sure that the PUBLIC user should not be able to add or change objects. PUBLIC USE is normally the best choice. Even with PUBLIC USE, you cannot prevent an ALLOBJ user from adding or changing an object. While you cannot prevent an ALLOBJ user from abusing the system, you can audit what an ALLOBJ user does. See the section on Auditing. Auditing -------- If you are not familiar with the system auditing capability, use DSPTAA AUDITING for a basic discussion and some of the TAA Tools that can assist. Auditing is an effective tool for allowing you to determine that functions are not being mis-used. This is a particular concern with users with ALLOBJ authority. There is no means of preventing an ALLOBJ user from mis-using the system. Knowing that an audit trail will exist can be an effective deterrent as well as a means of determining what happened. To check for various system library list exposures, ensure that the following system values include at least the following settings: Sys value Setting --------- ------- QAUDCTL OBJAUD QAUDLVL QAUDLVL2 QAUDLVL2 SECCFG (or SECURITY) You need OBJAUD as you will be auditing actions on designated objects. You need SECCFG to check changes to system values. The following sections describe how to audit the different aspects of the system library list and how to check for the auditing entries. Note that if you are going to test some of the conditions with TAA Tool commands (such as DSPAUDLOG), you will need to do CVTAUDLOG after each test. Auditing system values changes ------------------------------ The SECCFG (subset of SECURITY) audit level will cause an audit entry for any system value change. A 'T SV A' entry is made for any system value change and the new value is recorded. You can review the changes with DSPAUDLOG JRNCDE(T SV A). This will display any system value change. You may prefer the SCNAUDLOG TAA command where you can see just those involving the QSYSLIBL system value. SCNAUDLOG SEARCH(SYSLIBL) JRNCDE(T SV A) Auditing CHGSYSLIBL ------------------- To audit the CHGSYSLIBL command, enter: CHGOBJAUD OBJ(CHGSYSLIBL) OBJTYPE(CMD) OBJAUD(ALL) If the command is used, a 'T CD C' entry is generated. Since this type of entry is also made for any command that is being audited, you may prefer the SCNAUDLOG TAA command: SCNAUDLOG SEARCH(CHGSYSLIBL) JRNCDE(T CD C) Auditing additions and changes to a library ------------------------------------------- There are no good solutions for checking additions and changes to a library like QSYS. You can use CHGOBJAUD OBJ(QSYS) OBJTYPE(LIB) OBJAUD(CHANGE), but a journal entry is only written when an object is added to or deleted from QSYS. A better a more comprehensive solution is discussed in the next section. Auditing what ALLOBJ users do ------------------------------ The previously discussed methods can do a good job of preventing the PUBLIC user from mis-using the system library list, but they cannot prevent ALLOBJ users. Instead of trying to audit individual functions, it is typically better to audit the commands used by ALLOBJ users. Because auditing commands is tedious, you may decide to periodically audit users rather than continuous auditing. If so, you will want to use CHGUSRAUD AUDLVL(NONE), when you have completed auditing for a specific user. This assumes: ** That ALLOBJ users have a unique profile that is used when ALLOBJ functions are required. This will reduce the amount of entries that must be reviewed. ** Use auditing is specified as: CHGUSRAUD USRPRF(xxx) OBJAUD(ALL) AUDLVL(CMD) When an ALLOBJ user profile is used, any commands entered (including commands from CL programs or REXX procedures) cause a journal entry (T CD C). You can use the TAA Tool DSPAUDCMD to display or list the commands run by the user. DSPAUDCMD USER(xxx) The default is to display commands entered from a command entry display. If you want to display the CL commands used by a specific CALL, it is probably best to specify the PERIOD parameter with a begin/end date and time and use CMDTYPE(ALL). This will reduce the number of CL program commands that must be reviewed.

SYSLIBL         PROTECTING LIBRARIES ON SYSLIBL        TAAAUDB


The System  Library List tool  is a documentation  member only to  help
understand  the basics  of  how to  control  and audit  the  changes to
libraries  on the system library  list.  TAA Tools  that can assist are
also mentioned.

Why is controlling the system library list libraries important
--------------------------------------------------------------

The libraries  on the  system library list  become part  of every  job.
While the list  of libraries can be changed,  it normally includes QSYS
which  contains most of the system functions.   It is possible to place
a program or  command that  has the  same name as  a system  name in  a
library in  front of  QSYS and gain  control when a  user thinks  he is
executing a system function.

This  document discusses  how to  review what  is currently  being used
and how to control and audit changes.

The system library list
-----------------------

The system library  list is  determined by the  QSYSLIBL system  value.
You can display the value with:

            DSPSYSVAL  SYSVAL(QSYSLIBL)

The  shipped values  are  QSYS,  QSYS2,  QHLPSYS, and  QUSRSYS.    QSYS
contains  many object  types including  commands  and programs.   QSYS2
contains programs and other object types, but not commands.

It  is generally a good  idea to keep track of  what you have specified
so you  can compare  to the  current values.   The  TAA Tool  CAPSECINF
will  do this  for  system values  as  well as  user profiles,  network
attributes,  and  registration information.   See  the  tool discussion
for how to set it up.   You can use up a job scheduling job  to capture
the information  periodically.   You can then  compare any  two periods
to see what has changed.

CHGSYSLIBL Command
------------------

The system  provided CHGSYSLIBL command allows  the system library list
to be changed for the current  job (only the job executing the  command
would  be  affected).     You  should  review  who  is   authorized  to
CHGSYSLIBL with:

            DSPOBJAUT OBJ(CHGSYSLIBL) OBJTYPE(*CMD)

The command is  shipped as *PUBLIC *EXCLUDE.  You  would have to have a
very specific reason to allow the *PUBLIC any other usage.

If  you have  users that are  authorized to use  CHGSYSLIBL, you should
ensure you have done  so with a specific  reason in mind.  In  general,
there are  now many  other solutions  to allow the  tailoring of  a job
besides CHGSYSLIBL.  Using CHGSYSLIBL increases the security risk.

While  you may not have any users  authorized to CHGSYSLIBL, you cannot
prevent an  *ALLOBJ user  from using  the command.    While you  cannot
prevent the  use, you  can audit the  fact that it  occurred.   See the
later section on Auditing.

Placing a user library in front of QSYS
---------------------------------------

Some users  want to place a  user library in front of  QSYS so they can
change what  certain commands  do.   This  can  be effective  for  some
functions, but  increases the security  exposure that  system functions
can be mis-used.

As  of V5R4,  the system  supports the  capability  for a  command exit
which  is a safer method of changing the  action of a command.  See the
TAA Tool CMDEXIT for how to write a command exit.

Neither approach will work if  the user of a command you are  trying to
change uses a qualified name such as QSYS/xxx.

If  you  want  to audit  that  a  command  has  been used,  the  system
auditing  function  is  a  better function  than  attempting  to  use a
command exit.

If you have  such a library,  it is a  good idea  to track what  exists
and compare it the  previous information.  The TAA  Tool CMPLIB2 can do
this.   You  need the CAPLIB2  command to  capture the  information (it
creates an  outfile).   When you  want to  make a  comparison, you  use
CAPLIB2 again  and output  the outfile  to a different  library.   Then
use the CMPLIB2 command to compare the two sets of values.

You  could  also  use  the  same  technique  for  the  QSYS  and  QSYS2
libraries.

Authorizations to system library list libraries
-----------------------------------------------

You  should review  the authorizations  to the  libraries that  make up
the library list.   For each library on  the system library list  check
the authorizations such as QSYS with:

             DSPOBJAUT   OBJ(QSYS) OBJTYPE(*LIB)

The system  libraries like  QSYS are shipped  as *PUBLIC *USE.   Unless
you  have some specific reason,  the system libraries  are best left as
*PUBLIC *USE.

If you have a user library in  front of QSYS, you want to be sure  that
the  *PUBLIC  user  should  not  be able  to  add  or  change  objects.
*PUBLIC *USE is normally the best choice.

Even  with  *PUBLIC  *USE, you  cannot  prevent  an  *ALLOBJ user  from
adding or changing an object.

While you cannot prevent an *ALLOBJ  user from abusing the system,  you
can audit what an *ALLOBJ user does.  See the section on Auditing.

Auditing
--------

If  you are  not  familiar with  the  system auditing  capability,  use
DSPTAA AUDITING for  a basic discussion and some  of the TAA Tools that
can assist.

Auditing  is  an  effective tool  for  allowing you  to  determine that
functions are not  being mis-used.  This  is a particular concern  with
users  with *ALLOBJ  authority.   There is  no means  of  preventing an
*ALLOBJ  user from mis-using the  system.  Knowing that  an audit trail
will exist  can  be  an effective  deterrent  as  well as  a  means  of
determining what happened.

To check  for various  system library list  exposures, ensure  that the
following system values include at least the following settings:

       Sys value    Setting
       ---------    -------

       QAUDCTL      *OBJAUD

       QAUDLVL      QAUDLVL2

       QAUDLVL2     *SECCFG (or *SECURITY)

You  need  *OBJAUD  as  you  will  be  auditing actions  on  designated
objects.  You need *SECCFG to check changes to system values.

The following sections describe how  to audit the different aspects  of
the system library list and how to check for the auditing entries.

Note that  if you are  going to  test some of  the conditions with  TAA
Tool  commands  (such as  DSPAUDLOG),  you will  need  to do  CVTAUDLOG
after each test.

Auditing system values changes
------------------------------

The  *SECCFG  (subset of  *SECURITY) audit  level  will cause  an audit
entry for any system  value change.  A 'T  SV A' entry is made  for any
system value change and the new value is recorded.

You can  review the changes with  DSPAUDLOG JRNCDE(T SV A).   This will
display  any system  value change.   You may  prefer the  SCNAUDLOG TAA
command where  you can  see just  those involving  the QSYSLIBL  system
value.

        SCNAUDLOG   SEARCH(SYSLIBL) JRNCDE(T SV A)

Auditing CHGSYSLIBL
-------------------

To audit the CHGSYSLIBL command, enter:

        CHGOBJAUD   OBJ(CHGSYSLIBL) OBJTYPE(*CMD) OBJAUD(*ALL)

If the  command is used,  a 'T  CD C' entry  is generated.   Since this
type of  entry is also made for any command  that is being audited, you
may prefer the SCNAUDLOG TAA command:

        SCNAUDLOG   SEARCH(CHGSYSLIBL) JRNCDE(T CD C)

Auditing additions and changes to a library
-------------------------------------------

There are no  good solutions for  checking additions and  changes to  a
library  like QSYS.    You can  use  CHGOBJAUD OBJ(QSYS)  OBJTYPE(*LIB)
OBJAUD(*CHANGE),  but a journal  entry is  only written when  an object
is added to or deleted from QSYS.

A  better  a  more  comprehensive solution  is  discussed  in  the next
section.

Auditing what *ALLOBJ users do
------------------------------

The previously discussed  methods can do a  good job of preventing  the
*PUBLIC user  from mis-using the  system library list, but  they cannot
prevent *ALLOBJ users.

Instead  of  trying  to audit  individual  functions,  it  is typically
better to audit the commands  used by *ALLOBJ users.  Because  auditing
commands  is  tedious,  you  may decide  to  periodically  audit  users
rather  than  continuous  auditing.    If  so,  you  will want  to  use
CHGUSRAUD  AUDLVL(*NONE),  when  you  have  completed  auditing  for  a
specific user.

This assumes:

  **   That *ALLOBJ  users  have a  unique profile  that  is used  when
       *ALLOBJ  functions are required.   This  will reduce  the amount
       of entries that must be reviewed.

  **   Use auditing is specified as:

          CHGUSRAUD  USRPRF(xxx) OBJAUD(*ALL) AUDLVL(*CMD)

When  an *ALLOBJ user profile is  used, any commands entered (including
commands from  CL programs or  REXX procedures)  cause a journal  entry
(T CD C).

You can  use the  TAA Tool  DSPAUDCMD to display  or list  the commands
run by the user.

             DSPAUDCMD   USER(xxx)

The  default  is  to  display commands  entered  from  a  command entry
display.

If you want to display the CL  commands used by a specific CALL, it  is
probably best  to specify  the PERIOD parameter  with a  begin/end date
and  time and  use CMDTYPE(*ALL).   This will  reduce the number  of CL
program commands that must be reviewed.

Added to TAA Productivity tools April 15, 2011

Home Page

Up to Top