Re: Wayne Evans' LOGCMD

Steve McKay wrote on 05/05/2008 03:44:54 PM:

> I've played with this most of the day and have come to the conclusion
that
> you're correct - Wayne's trick of swapping to the same user profile
without
> specifying *CURRENT has probably been PTFed and no longer works.  Here is

> the code in question:
>
> CALL       PGM(QSYGETPH) PARM(&USER '*NOPWD' &LOGCMD)
> CHGUSRAUD  USRPRF(&USER) AUDLVL(&AUDLVL)
> CALL       PGM(QWTSETP)  PARM(&LOGCMD)
> CALL       PGM(QSYRLSPH) PARM(&LOGCMD)
>
> When I execute this part of the program followed by a call to QCMD, the
> &USER user profile (my user profile) has *CMD as an "auditing action" but

> subsequent commands entered do not show up in QAUDJRN.  If I immediately
> sign off and back on, all commands entered after sign on are logged to
> QAUDJRN, so it appears that the warning in CHGUSRAUD about changes not
> taking effect until another job is started for the user is being
enforced.
>
> Do I have other options without setting everyone's profile auditing
action
> to *CMD or executing the *SPENDMONEY (RIP Al B.) command?

That code is very close but not correct. Before I share code that does work
on V6R1 (and probably other releases) I will first say that I do not like
the idea of giving any user access to a command line where they have
*ALLOBJ authority. Doing this is almost as bad as giving them *ALLOBJ all
of the time. They can do virtually anything on the system. So the only
group of people I would give authority to run the following program are
those people that I would be willing to give two user profiles, one with
*ALLOBJ authority and one without. With this program you only have to
create the user profile without *ALLOBJ authority. So most of the time they
are running without *ALLOBJ authority.

The key to the program is that the profile must be changed before the
profile handle for that user profile is created. (Someone must have moved
the CHGUSRAUD command in Wayne's LOGCMD program.)  Instead of just adding
*CMD auditing I decided it was less work and better for security to just
turn on all auditing for the user profile. (That way I did not have to
figure out what auditing was already turned on for the user.)  If your
system is not at V6R1, some of the AUDLVL value on the CHGUSRAUD command
will not be supported.  If that is the case I suggest adding a MONMSG after
the CHGUSRAUD and trying the command again with the values that will work
on your system. That way when you do move to V6R1 the program will continue
to turn on all auditing.

One other thing I did is call QUSCMDLN instead of QCMD. I did this to help
remind people that are used to using QCMD, that they are in a different
environment. Hopefully they will be encouraged to get off the pop-up
command line and back to their normal environment.

PGM
  DCL        VAR(&CURRENT) TYPE(*CHAR) LEN(12)
  DCL        VAR(&SAMEUSR) TYPE(*CHAR) LEN(12)
  DCL        VAR(&USER) TYPE(*CHAR) LEN(10)
  DCL        VAR(&OBJAUD) TYPE(*CHAR) LEN(10)
  DCL        VAR(&AUDLVL) TYPE(*CHAR) LEN(640)

  QSYS/RTVUSRPRF  RTNUSRPRF(&USER) OBJAUD(&OBJAUD) AUDLVL(&AUDLVL)
  QSYS/CHGUSRAUD  USRPRF(&USER) OBJAUD(*ALL) AUDLVL(*AUTFAIL *CMD +
                    *CREATE *DELETE *JOBDTA *NETCMN *OBJMGT *OFCSRV +
                    *OPTICAL *PGMADP *PGMFAIL *PRTDTA *SAVRST +
                    *SECURITY *SERVICE *SPLFDTA *SYSMGT)
  CALL       PGM(QSYS/QSYGETPH) PARM('*CURRENT' '*NOPWD' &CURRENT)
  CALL       PGM(QSYS/QSYGETPH) PARM(&USER      '*NOPWD' &SAMEUSR)
  CALL       PGM(QSYS/QWTSETP)  PARM(&SAMEUSR)
  CALL       PGM(QSYS/QSYRLSPH) PARM(&SAMEUSR)

  CALL       PGM(QSYS/QUSCMDLN)

  QSYS/CHGUSRAUD  USRPRF(&USER) AUDLVL(&AUDLVL)
  CALL       PGM(QSYS/QWTSETP)  PARM(&CURRENT)
  CALL       PGM(QSYS/QSYRLSPH) PARM(&CURRENT)

ENDPGM

You pointed out one problem with programs like this. If the user of the
program signs-off at the command line or their job is ended for any reason
then they will continue to have all auditing turned on.  You may be able to
solve that problem by using a scope message to call another program to
restore auditing for the user profile. Or, this may be the case where it is
time to spend money for a product that solves this and other(?) problems.

Something else to think about. Instead of using this program perhaps you
should create one that uses the adopted authority to swap to a user profile
that has the necessary special authorities and auditing already turned on.
Then call QUSCMDLN and then swap back. That way you do not have to clean up
the users profile if the job ends. The security audit records will contain
both user profiles, the initial one in the job name fields and the current
user profile field.

Ed Fishel,
edfishel-r/[email protected]

_______________________________________________
This is the Security Administration on the AS400 / iSeries (Security400) mailing list
To post a message email: Security400-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/security400
or email: Security400-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/security400.