TAA Tools

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:


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.


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


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

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:


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

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.


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



To audit the CHGSYSLIBL command, enter:


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:


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

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:


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

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