Sign In

Dz Challenge: Tips and Techniques Got a great tip or technique to share?
z & A > Dz Challenge: Tips and Techniques > Front-ending TSO/E commands without altering IBM code. View modes: 
User avatar
Member
Member
jan - 4/28/2012 9:08:55 AM
   
Front-ending TSO/E commands without altering IBM code.
In my 25+ years as a free lance MVS-OS/390-z/OS systems programmer I have often
seen coding that modified IBM TSO/E commands by front-ending them with
assembly code. Even worse if this was not even implemented with a usermod(SMP/E). Needless to say this is not only dangerous because the front-end runs with z/OS authorization, but it is more often than not also difficult code to
maintain. Sometimes however it is a good idea to change the z/OS default command
logic.

The idea I am presenting here is basically very simple, you create a Rexx exec in a member; with the same
name as the command, in a dataset in your SYSEXEC or SYSUEXEC
concatenation. The exec accepts all arguments but does some processing before it passes the parameters to the command processor, and
eventually adds complementary processing. Execute the exec with '%COMMAND'
and the real command with 'COMMAND'.

Example 1.

If you do an RLIST, RACF will by default try to figure out your access. For
a normal class, RACF can find out easily enough by analyzing the access list.
Things are different for grouping/member classes where RACF will do
retrieval and RACLIST processing of all grouping class profiles in order to
determine your access. This can be very CPU intensive and mostly you are
not interested in your own access anyway. You can avoid this overhead by adding
NOYOURACC or NOY to the RLIST command. The small rexx below called RLIST
does exactly that, it adds the parameter NOYOURACC unless it is already
there. Execute it with '%RLIST' with the same parameter list as the real
command.

Example 2

If you execute an 'ADDUSER' command, the last used day is not set. This
means that there could be userids defined that linger for years without
being detected as 'last logon date too old'. Worst case is when their
passwords defaulted to their default group at the moment of creation. To
avoid this situation, create a Rexx exec called 'ALTUSER' (see below) who
executes exactly your ALTUSER command but adds a ALTUSER RESUME command
afterwards. This has the effect of setting the 'last use' date to today, meaning
that the user will be revoked after a system defined period of inactivity.
This will show up as 'LAST-ACCESS=' in the 'LISTUSER' output. To be
complete, also create a Rexx exec called AU, which is an exact copy of the
ALTUSER one..

These are just 2 examples to show the idea. It can be used to implement
site specific defauls for all kinds of TSO/E commands without worrying
about assembler, maintenance and/or release changes of IBM coding.

It must be emphasized that you _CAN_NOT_ rely on this technique for security. If
for instance you eliminated the OPERATIONS attribute by implementing ADDUSER & ALTUSER rexx exec equivalents, the real commands can still be
(ab)used.

I am interested to know if you use or going to use this technique. If this is the case, you can
send me a mail: jan@jedsp.net

Best regards,

j@n


====================
REXX RLIST
====================
/* Rexx program that adds NOYOURACC unless YOURACC is specified
*/
parse arg parameters

/* Check for both YOURACC and NOYOURACC (or NOY)
*/
if (pos('YOURACC', parameters) <> 0) ,
& (pos('NOYOURACC', parameters) <> 0 ! ,
pos('NOY', parameters) <> 0) then do
say 'You cannot specify both YOURACC and NOYOURACC (or NOY)'
exit(8)
end
/* If YOURACC is specified, eliminate it from the command
*/
if pos('YOURACC', parameters) <> 0 then do
parse var parameters before 'YOURACC' after
parameters = before after
end
/* If NOYOURACC nor NOY is specified, add NOYOURACC to the command
*/
else if pos('NOYOURACC', parameters) = 0 ,
& pos('NOY', parameters) = 0 then do
parameters = parameters 'NOYOURACC'
end
address "TSO" "RLIST" parameters

exit(0)

1