:::::::::::::::::::::::::::::::::::::::::::::
:: HP's 'SECURITY/3000' System (part 2/3) ::
:: ::
:: by Sterling ::
:: ::
:::::::::::::::::::::::::::::::::::::::::::::
SECURITY/3000 is a third party security package for use on HP 3000 series
computers. It replaces several commands and bundles several utility programs
to monitor system security. HP's are quite a common site on X.25, so this may
add to your understanding of what's going on. Part 1 of this manual can be
found in Informatik #02. In this second section, I will discuss several of the
companion utilities that SECURITY/3000 uses to protect logins and passwords.
OBSOL - MPE passwords OBSOLESCENCE system
*****************************************
INTRODUCTION
~~~~~~~~~~~
A password is only as good as the people who are supposed to keep it secret.
The fact of the matter is that in most shops, MPE passwords get out "through
the grapevine" within a month or so at most. By the end of the month, the
passwords have to be changed to ensure security.
OBSOL, the Password Obsolescence System, guarantees that passwords are changed
frequently, and system security is thus maintained.
HOW OBSOL WORKS
~~~~~~~~~~~~~~
An Account Manager or the System Manager determines the number of days a given
password (user, group, or account) is valid before it must be changed (the
period called "obsolescence days"), and the number of days before the password
becomes obsolete that the user will be warned that the password will expire
(the period called "warning days").
Whenever a user logs on during a period when the password should be changed, he
is notified on what date the password will expire and then is allowed on the
system. If he logs on after the password has expired, he is disallowed access
to the system.
Every time an Account or System Manager changes a user, group, or account
password, he is prompted for the "obsolescence days" and "warning days" which
should be applied for that password, and the password obsolescence system is
updated automatically.
WHAT HAPPENS AT LOGON TIME
~~~~~~~~~~~~~~~~~~~~~~~~~
Whenever a user logs on during a period when either or both his user or account
passwords should be changed, he is notified that the password(s) will expire
and is then allowed on the system, as follows:
***********************************************************
Your xxxxxxxx password will expire on mm/dd/yy!
***********************************************************
where 'xxxxxxxx' is the type of password (user, group or account), 'mm/dd/yy'
is the obsolescence (expiration) date.
If a user logs on after the group or account password has expired, he is
disallowed access to the system and the following message is displayed:
***********************************************************
Your xxxxxxxx password has expired!
You will not be able to sign on until it is changed.
***********************************************************
where 'xxxxxxxx' is the type of password (user, group, account).
The password obsolescence system will not warn a user about the group password
if the group he is logging into is his home group--this is in keeping with MPE,
which does not prompt a user for his home group password, even if one exists.
By the same token, a user will not be disallowed access to a group, if that
group is his home group, even if the password has expired. In general, a user
will be warned to change only those passwords which he is prompted for at
logon.
OBSOL/PASCHG INTERFACE
~~~~~~~~~~~~~~~~~~~~~
OBSOL works well with PASCHG, the system which permits users to change their
own MPE user passwords, since with PASCHG the Account Manager is not burdened
with having to change dozens of passwords at the end of every month. In order
to provide additional ease in making certain that passwords are changed, OBSOL
may be configured to automatically run PASCHG during the password warning
period.
ACTIVATING OBSOL
~~~~~~~~~~~~~~~
The core of the password obsolescence system is two UDC files.
The first one is an option logon UDC which runs the program
OBSLOG.PUB.SECURITY
which checks whether any of the passwords of the user who is logging on are
obsolete.
The UDC is stored in the file OBSOLUDC.PUB.SECURITY
OBSLOGON
OPTION LOGON, NOBREAK
SETJCW SECURITYANSWER=0
RUN OBSLOG.PUB.SECURITY
IF SECURITYANSWER = 1 THEN
BYE
ENDIF
and should be set for a user, account, or the entire system; e.g. to set it
for the logon account, the Account Manager can do the following:
:SETCATALOG OBSOLUDC.PUB.SECURITY;ACCOUNT
It's recommend that the system manger set this UDC on an account-by-account
basis.
The second set of UDCs redefines all MPE :NEWUSER, :NEWGROUP, :NEWACCT,
:ALTUSER, :ALTGROUP, and :ALTACCT commands to run the program
OBSCHG.PUB.SECURITY
which updates the password obsolescence system whenever one of these commands
is executed.
These UDCs are stored in the file
OBSUDC.PUB.SECURITY
and are usually set systemwide so that all :ALTxxx and :NEWxxx commands are
redefined throughout the system. To do this, log on as MANAGER.SYS and execute
the command
:SETCATALOG OBSUDC.PUB.SECURITY,.. your UDCs...;SYSTEM
CONFIGURING OBSOL
~~~~~~~~~~~~~~~~
The default "obsolescence days" and "warning days" is set by declaring them in
the SECURITY/3000 configuration file
SECURMGR.PUB.SECURITY
as follows:
OBSDAYS=obsdays
WARNDAYS=warndays
where 'obsdays' is the number of days that a password is valid for before it is
obsoleted (default is '30') and 'warndays' is the number of days before a
password expiration is warned about.
EXCLUDING CERTAIN PASSWORDS FROM OBSOLESCENCE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you want to have some passwords expire automatically and others not, you can
accomplish this by declaring a long period of time (e.g. 1000 days) as the
"obsolescence days" for that password.
Only entities (users, groups, and accounts) in MPE which have passwords are
included in the password obsolescence system--those without MPE passwords are
not included in the internal data base when it is filled. In keeping with
this, when a password is removed from an entity in MPE, the entry corresponding
to that entity is removed from the data base. Similarly, when anDS; ADDING AND
ALTERING USERS, GROUPS, AND ACCOUNTS
When adding or altering users, groups, and accounts in OBSOL, the :NEWUSER,
:NEWGROUP, :NEWACCT, :ALTUSER, :ALTGROUP, and :ALTACCT commands are used as in
MPE, except the syntax is slightly different: the body of the command must be
enclosed in quotation marks, as in
:NEWUSER "CLERK;PASS=XYZZY;CAP=ND,SF,IA,BA"
and
:ALTACCT "DEV;PASS=FOO;CAP=AM,AL,GL,ND,SF,IA,BA,PH,DS"
These commands are redefined by UDCs to not only execute the command but, if
the command changes a password, to inform OBSOL that the password has been
changed and that it should be obsoleted when the "obsolescence days" have
passed. Therefore, it is not necessary to explicitly run a special program to
inform OBSOL every time a password is changed.
When you execute a :NEWxxx or :ALTxxx commmand, the command is processed
normally and you are prompted for "obsolete days" and "warning days" as
follows:
Password is currently obsoleted every od days; new value:
Where 'od' is the current "obsolescence days". Enter the new period for which
the password should be valid before it is obsoleted, or hit <return> to retain
the same value as before.
Warning period before obsolescence is wd days; new value:
Where 'wd' is the current "warning days". Enter the new number of days before
a password expires that the user should be warned to have the password changed,
or hit <return> to retain the same value as before.
So, for example, if you want to change the GAMES account password, and you want
the new password to be obsoleted every 2 months (60 days) and a warning message
that the password is about to expire displayed during the 5 days before the
password will expire, execute the command:
:ALTACCT "GAMES;PASS=FUNTIME"
and respond to the prompts as follows:
Password is currently obsoleted every 30 days; new value: 60
Warning period before obsolescence is 7 days; new value: 5
For a more critical password on a more sensitive account, such as the PAYROLL
account, you may want to obsolete the password every 14 days with 3 days of
warning, as follows:
:ALTACCT "PAYROLL;PASS=BIGBUCKS"
and then answer the prompts as follows:
Password is currently obsoleted every 30 days; new value: 14
Warning period before obsolescence is 7 days; new value: 3
WHAT IS DONE WHEN A PASSWORD EXPIRES
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a user password has been obsoleted (expired), the user should have his
Account Manager change the password to permit the user to log on. If an
account password has been obsoleted, the Account Manager should have the System
Manager change that password to permit users of that account to log on.
In a situation where a user password of an Account Manager or of the System
Manager has expired, there is no one with the capabilities to change the
password; therefore, it is necessary to modify the internal data base according
to the following example:
1. :HELLO MANAGER.SECURITY,DATA
2. :RUN QUERY.PUB.SYS
>BASE=OBSOL
PASSWORD= >>; << enter a ';' >>
MODE = >>1
3. >FIND USER+ACCT ="MANAGER VESOFT " << if USER password >>
>FIND ACCT+GROUP="VESOFT DEV " << if GROUP password >>
>FIND ACCT=VESOFT << if ACCOUNT password >>
4. >REPLACE OBS-DAYS="500"; END
>EXIT
This will temporarily "un-obsolete" the password, allowing the Account or
System Manager to log on. Once logged on, he should change the password and
re-define "obsolescence days" when prompted.
ACCESSING THE OBSOL DATA BASE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The password obsolescence data base is
OBSOL.DATA.SECURITY
and contains the following data sets:
OBS-ACCT
OBS-USER
OBS-GROUP
The data base contains information about all the passworded users, groups, and
accounts on the system. IT DOES NOT CONTAIN THE MPE PASSWORDS. The valid data
items are as follows:
LAST-CHG-DATE the date (in YY/MM/DD format) that the password
was last changed
OBS-DAYS number of obsolescence days
WARN-DAYS number of warning days
Ignore DUMMY1, DUMMY2, and FILLER--they're just there for SECURITY/3000's
convenience.
For added security, it is normally recommended that the system manger change
the data base password (as follows) and the password obsolescence system will
still be able to (magically!) access the data base:
:HELLO MANAGER.SECURITY,DATA
:RUN DBUTIL.PUB.SYS
>>SET OBSOL PASSWORD 1=password
>>EXIT
TERMPASS -- passwords DIAL-UPs, terminals, DS lines, LANs, etc.
***************************************************************
INTRODUCTION
~~~~~~~~~~~
With the current explosion in datacom and with HP providing all supported sites
with telesupport modems, nearly every HP3000 site has dial-up access.
With the added benefits and convenience that dial-up access provides, a whole
new world of security considerations emerges: the system is threatened not
only by users within your company or on your premises, but by anyone with a
terminal or microcomputer, a telephone, and a modem!
With the current wave of computer crime and the new breed of "hackers" whose
enjoyment comes from wreaking havoc <sic> on computer systems, special security
must be placed on dial-up lines.
TERMPASS implements this extra security not only on dial-up lines but on DS
lines, terminals, and anything else that supports interactive communication
(MTS, LAN, X.25, etc.). Unfortunately, although MPE permits user, account, and
group passwords, it does not allow one to set terminal passwords. TERMPASS
allows the System Manager to set a password on any LDEV, which must be answered
correctly by the user at logon time to gain access to the system.
In addition, it allows you to marry the high level of user authentication that
the Logon Security System provides with the terminal and dial-up security that
TERMPASS gives you. You can implement the Logon Security System not only on
certain accounts and certain users, but also based on which device a user is
logging on to.
HOW TERMPASS WORKS
~~~~~~~~~~~~~~~~~
TERMPASS is configured by specifying which LDEVs are to be passworded and what
the passwords are. Then set a systemwide logon UDC which will run the TERMPASS
program whenever users log on.
Whenever a user logs on to a terminal which has been configured with a
password, after he correctly answers required MPE passwords, he is prompted for
the terminal password for that terminal. If he answers correctly, he is
allowed on the system. If he answers incorrectly, he is denied access to the
system (i.e. logged off, an inverse-video message describing the failed logon
attempt is sent to the console, and an entry is logged to the SECURITY/3000 log
file.
SETTING PASSWORDS ON SPECIFIC LDEVs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can configure TERMPASS by specifying which terminals are to be passworded
and what the passwords are. To do this, build the file
TERMPASS.DATA.SECURITY
with your editor, and add one line for each terminal to be passworded in the
format
LDEV password
where 'LDEV' is the logical device number of the terminal (e.g. '20') to be
passworded and 'password' is the password (e.g. 'OPERONLY'). Any terminal not
included in this file will remain unpassworded.
So, for example, if you created the TERMPASS data file in your editor as
follows:
:EDITOR
/ADD
1 20 OPERONLY << the console >>
2 21 WARGAMES << a dial-up line >>
3 22 XYZZY << a terminal >>
4 65 KEEPOUT << a DS line >>
5 //
/KEEP TERMPASS.DATA.SECURITY,UNN
/EXIT
then the passwords specified would be placed on the corresponding LDEVs.
AFTER YOU /KEEP THIS FILE (AND AFTER ANY SUBSEQUENT /KEEPs), YOU MUST
:ALTSEC TERMPASS.DATA.SECURITY;(R,X,A,L,W:CR)
THIS IS EXTREMELY IMPORTANT! IF YOU DO NOT DO THIS, ANYBODY WILL BE
ABLE TO READ THIS FILE! YOU MAY ALSO USE A LOCKWORD TO PROTECT
THIS FILE:
:RENAME TERMPASS.DATA.SECURITY, TERMPASS/lockword.DATA.SECURITY
DISABLING A TERMINAL WITH AN ATTEMPTED REMOTE LOGON VIOLATION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If a user is unsuccessful in logging on through a dial-up line or an inhouse
terminal configured with TERMPASS, it is often desirable to "hang" that LDEV or
terminal so that further logon attempts are not possible.
To do this, determine the time in seconds for which you would like the LDEV or
terminal hung and then add a line to the TERMPASS.DATA.SECURITY file in the
format:
PAUSE=numseconds
where 'numseconds' is the number of seconds for which the terminal will be
hung. Then, when a user has an unsuccessful logon attempt, he will be hung for
the amount of time specified.
By default, 'numseconds'=0 which means that the user will not be hung at all.
SPECIFYING NUMBER OF ATTEMPTS TO ANSWER TERMINAL PASSWORD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may specify the number of attempts users are allowed to answer the terminal
password at logon by adding a line to the TERMPASS.DATA file in the format:
TIMES=attempts
where 'attempts' is the number of times the terminal password will be asked.
By default, 'attempts'=1.
LOGGING SUCCESSFUL REMOTE LOGONS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may wish to know who is logging on through the dial-up line, or whether a
particular logon is being utilized. You may also feel relieved to see that an
unsuccessful attempt is directly followed by a successful attempt, meaning that
the error was probably a typo. You may enable SECURITY/3000 to log successful
logons which pass through the TERMPASS program by adding a line to the
TERMPASS.DATA.SECURITY file in the format:
LOG-LOGON=ON
This keyword will be seen by the REMOTE security system and cause all
successful logons to be written to the LOG.DATA.SECURITY file for later review.
No other configuration is required and this keyword may be added or removed at
any convenient time. When the log file is later reviewed (see HOW TO LIST THE
SECURITY LOG FILE in the LOGON section of this manual) the message:
'SUCCESSFUL REMOTE LOGON' will be displayed.
INVOKING THE LOGON SECURITY SYSTEM VIA TERMPASS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Generally, the Logon Security System in SECURITY/3000 (personal profile
passwords, time, day, and menu restrictions) are imposed on certain users and
accounts by setting a UDC (SECURUDC.PUB.SECURITY) on that user or account; then
all the users who have that UDC set must go through SECURITY/3000 to log on
However, you can also impose the Logon Security System on users logging on to
certain devices instead of (or in addition to) users on which SECURUDC has been
set. Say, for example, you want to have the Logon Security System run EITHER
on the users/accounts on which you've set SECURUDC OR on any accesses to the
system from certain LDEVs (e.g. dial-up modem ports, DS line ports, terminal
ports, etc). For example, to set things up so that anybody who EITHER uses the
PAYROLL account OR signs on to LDEV 36 (or both) will have to go through the
Logon Security System, declare a line in the TERMPASS configuration file,
TERMPASS.DATA.SECURITY, which looks like this:
36 SECRET $SECURITY
Note that LDEV 36 still has a terminal password ("SECRET"); but, because there
is a '$SECURITY' keyword on that line means that IN ADDITION TO TERMPASS asking
the terminal password, the Logon Security System will always be run for all
logons to LDEV 36.
If you want to, you can implement the Logon Security System on an LDEV without
placing a password on that LDEV - just omit the terminal password ("SECRET")
while keeping the $SECURITY keyword, leaving the line looking like
36 $SECURITY
Note that you still have to set the TERMPASS UDC (TERMUDC.PUB.SECURITY) on a
system-wide basis, since it's the TERMPASS program that checks the
TERMPASS.DATA.SECURITY file and invokes SECURITY/3000's Logon Security System
if it finds the $SECURITY keyword associated with the logon LDEV.
So, for example, TERMPASS.DATA.SECURITY might look like:
20 OPERONLY
25 $SECURITY
36 SECRET $SECURITY
This would mean that LDEV 20 has the password "OPERONLY" but won't have
SECURITY/3000 automatically invoked; 36 has the password "SECRET", and anybody
who logs on to it would have to go through the Logon Security System; and LDEV
25 has no terminal password, but all people who use it will be checked by the
Logon Security System.
Meanwhile, SECURUDC is still set on the PAYROLL account, and on whatever other
users or accounts you want to always be secured; the Logon Security System will
be run on them whether or not the user is using LDEV 25 or 36.
Of course, every user who will ever go through the Logon Security System - this
includes every user who will ever sign on to LDEV 25 or 36--must be put into
the SECURITY database using the ADD option of USER.PUB.SECURITY. This actually
is quite good, since it gives you the opportunity to allow only certain users
to use LDEV 25 or 36 - just authorize only those users, and all others will be
automatically forbidden.
Note that the Logon Security System can thus be called either from the TERMPASS
UDC (TERMUDC.PUB.SECURITY) you set up on a system-wide basis or the Logon
Security System UDC (SECURUDC.PUB.SECURITY) you set up on each account or user.
What if a user signs on to a secured account using a secured terminal? Well,
you don't want to make him go through the Logon Security System twice, so if
the Logon Security System was already run via TERMPASS, it won't be run again.
STREAMX/3000 - ELIMINATES THE NEED TO EMBED PASSWORDS AND OTHER
SENSITIVE INFORMATION IN JOB STREAMS
************************************************************************
INTRODUCTION
~~~~~~~~~~~
In MPE, all job streams must contain the passwords for the user, account, and
group under which they are to be streamed. Needless to say, this is a huge
security hole because anyone who has READ access to the file can look at it and
see the passwords. What's more, any listing of the job stream (of which plenty
are liable to be laying around the computer room) contains the password.
Furthermore, although MPE passwords are not echoed to the screen when you log
on, they are when you're working on a job stream in the editor. Who is looking
over your shoulder at your password on the screen? If you are working on a job
and walk away from your terminal, who can read it? Do you always clear the
screen when you walk away from the terminal--or even when you log off?
More importantly, since changing a password means having to change every single
job stream that contains it, MPE passwords are virtually guaranteed never to be
changed.
Some HP3000 sites work around this problem in a variety of ways, few of which
are very effective. A common "solution" is to create a dummy user (e.g.
'JOB') who exists solely for the purpose of streaming jobs, and remove his IA
capability--this can be gotten around quite easily by logging on with a :JOB
command and prefixing every command with a ':'. Others try to use the MPE file
security to restrict READ access to job stream files, but forget to :ALTSEC the
file to replace the file security after every /KEEP of the file (which waives
the prior file security).
THE SOLUTION
~~~~~~~~~~~
STREAMX/3000 closes this security hole by eliminating the need to embed MPE
passwords in job streams. It also eliminates the need to embed other sensitive
information in job streams, such as data base passwords, file lockwords,
:REMOTE HELLO passwords, etc. STREAMX also adds flexibility to job streams by
allowing you to pass parameters.
The logical alternative to embedding passwords in job streams is to prompt for
the passwords at :STREAM time, just as session passwords are prompted for at
:HELLO time. This is what STREAMX does. And to make life easier, if you have
enough capabilities to retrieve the passwords, they will be answered for you
automatically.
HOW STREAMX WORKS
~~~~~~~~~~~~~~~~
When you stream a job, STREAMX will analyze the job stream, as well as all the
job streams streamed by it, and will prompt you for all the passwords needed as
well as any parameters for which you have instructed STREAMX to prompt. Then,
it will incorporate the passwords and parameters into the job stream (without
changing the actual disc file), and then stream it.
As in MPE, the output file of the job stream will not contain the passwords.
Naturally, STREAMX will not prompt you for passwords that do not exist. If the
job stream already has the correct passwords embedded in it, those passwords
will not be prompted for; on the other hand, if the passwords embedded in the
stream are incorrect, they will be prompted for. This permits you to change
your MPE passwords and begin using STREAMX right away.
Also, if you have enough capabilities to retrieve the passwords in MPE (via
:LISTUSER, :LISTACCT and :LISTGROUP or LISTDIR), STREAMX will automatically
generate the passwords without any prompting (because, after all, you can find
them out anyway). This means that if you are an Account Manager streaming a
job in your account or an ordinary user streaming a job with the same user ID,
STREAMX will automatically generate the passwords (because you had to know them
to sign on). If you are the System Manager (or have SM capability), STREAMX
will never prompt you for a password because you can retrieve any password on
the system.
WHICH USER STREAMED A JOB? (ENHANCED JOB $STDLIST)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
STREAMX will enhance the $STDLIST of a job to contain some additional
information. The logon user ID of the user streaming the job and the LDEV from
which the job was streamed will be written to the job's output file, e.g.
:COMMENT STREAM FILE UPDATE.PUB.PAYROLL
:COMMENT STREAMED BY JOAN,CLERK.PAYROLL,PUB ON LDEV 26
so you can determine not only who the job logged on as, but also who actually
streamed it. If the job stream was launched from another job stream, the user
ID (from the !JOB card) of the first job stream will be written to the output
file, as well as the user who streamed that job stream.
PERMITTING THE SYSTEM OPERATOR TO STREAM ANY JOB STREAM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In many installations, the system operator (OPERATOR.SYS) is responsible for
streaming system job streams which accomplish backups, etc. STREAMX will
prompt the operator for the password for each !JOB card; but you may not want
to disclose various passwords to the operator.
As you know, STREAMX will not prompt for the passwords if a user has enough
capabilities to retrieve them, e.g. MANAGER.SYS can stream any job on the
system without being prompted for the passwords; but you do not want to give
your operator SM capability to accomplish the streaming of system job streams.
A good solution is to put all the system job streams in a special
group, e.g. JOB.SYS, and set up a UDC which the operator will use to stream
the jobs which will also temporarily allow the user SM capability for the
duration of streaming the job.
The following UDC runs the GOD.PUB.VESOFT program which gives the user SM
capability, then runs STREAMX to stream the job, and then runs
MORTAL.PUB.VESOFT to reset the user's capabilities to their original state.
Notice that the UDC is OPTION NOBREAK and contains a CONTINUE command so that
after the program GOD is run, there is a very high probability that the
capability reduction program MORTAL will execute. This increase and subsequent
guaranteed reduction of capability is what makes this UDC successful. Notice
also that the UDC has the option NOLIST. If the operator could see the text of
the UDC executing, then the operator would know the lockword to the program
GOD. Additionally, the UDC option NOHELP has been specified to prevent the
operator from :HELP OPSTRM which also reveals the program GOD's lockword.
OPSTREAM filename
OPTION NOHELP, NOLIST, NOBREAK
FILE STRMFILE=!FILENAME.JOB.SYS
RUN GOD/lockword.PUB.VESOFT
CONTINUE
RUN STREAMX.PUB.SECURITY;PARM=1
RUN MORTAL.PUB.VESOFT
RESET STRMFILE
There are two other important technical issues to be mentioned. First, the
operator should not be able to write to, nor save a file into the controlled
group JOB.SYS. Otherwise, the operator could create a job stream which logs on
as MANAGER.SYS and LISTDIR's all the MPE passwords. If the operator has write
access, there is no need to save a special file into the controlled group
JOB.SYS - just write over one that is already there. Second, the operator
should not have READ access to the UDC file which contains the lockword to the
program GOD. If both these points are maintained, the operator will not be
able to circumvent the intent. Note also that in order to :SETCATALOG a UDC
file you must have READ and LOCK access to it. This means that an ordinary
setcatalog of the UDC file will not provide adequate security (read access is
not permissable). The solution is to use a LOCKWORD to protect the UDC file
OPSTRM. This means you can release the file and then assign it a lockword.
Now when you :SETCATALOG the file, you must specify the lockword also (e.g.
:SETCATALOG OPSTRM/secret).
BUT - the file COMMAND.PUB.SYS has read access for all users, thus it can be
scanned and the lockwords with which UDC's are set can be determined. Also -
if someone is reading this file (say, with FCOPY, QUAD, etc.), another process
cannot resolve its UDC catalog. This is especially of concern where OPTION
LOGON UDCs are invoking SECURITY. Be sure to reduce the general access to
COMMAND.PUB.SYS so that the file may only be Locked and Xecuted - by :ALTSEC
COMMAND.PUB.SYS;(L,X:ANY).
So - with this UDC set for the operator, whenever the operator types
:OPSTREAM filename
the job stream filename.JOB.SYS will be streamed and the passwords needed on
the !JOB card will be resolved automatically - regardless of the job's logon
user ID.
LOCKWORDS
~~~~~~~~
Just as you shouldn't embed passwords into your job streams, you shouldn't
embed lockwords, either. If you have a lockword on, say, QUERY.PUB.SYS, you
might have a line in your job stream like
!RUN QUERY/?WHAT IS THE QUERY.PUB.SYS LOCKWORD?.PUB.SYS
Or, even better, you can say
!RUN QUERY/?$NOECHO$ WHAT IS THE QUERY.PUB.SYS LOCKWORD?.PUB.SYS
which won't echo the user's response.
However, STREAMX has an even better way of doing this! If you say
!RUN ?$LOCKWORD=QUERY.PUB.SYS$?
then STREAMX will automatically ask the user for the QUERY.PUB.SYS lockword, or
-- if the user is the system manager or the account manager of the SYS account
(the account in which QUERY.PUB.SYS resides) -- automatically supply the
lockword. This is just like the way STREAMX treats :JOB card passwords -- it
asks for them when necessary, but automatically supplies them when appropriate.
For instance, if the person streaming the job stream has SM capability and the
QUERY.PUB.SYS lockword is FROBOZZ, STREAMX will automatically convert the
!RUN ?$LOCKWORD=QUERY.PUB.SYS$?
to a
!RUN QUERY/FROBOZZ.PUB.SYS
On the other hand, if the streaming user doesn't have SM/AM capability, STREAMX
will prompt him with
WHAT IS THE LOCKWORD OF THE FILE 'QUERY.PUB.SYS'?
and will use the user's answer (entered without echo, of course) as the
lockword to be put into the job stream.
Back to the master Table of Contents.