The HP3000's 'SECURITY/3000' system (part 3)
by Sterling
The third and final part of our series on HP3000 Security.
STREAMX/SLEEPER -- LINKS STREAMX WITH SLEEPER
*********************************************
INTRODUCTION
~~~~~~~~~~~~
A very popular program from the Contributed Software Library (CSL) is SLEEPER,
which can stream a job, run a program, or execute a command or any combination
of these at any specified time and repeat this action at specified intervals.
Many HP3000 sites use SLEEPER to launch job streams at specified times during
the day or night, and at regular intervals (for instance it might run a report
program each night at 12:00 and stream a job which does a sysdump at 7:00 a.m.
each Friday).
But to stream a job using SLEEPER, the MPE passwords must be embedded in the
job stream. A better solution would be to use STREAMX in conjunction with
SLEEPER and have STREAMX generate the passwords.
SLEEPER INSTRUCTIONS
~~~~~~~~~~~~~~~~~~~~
Those familiar with SLEEPER know that the file 'SLEEPCOM' must first be built
as follows:
:BUILD SLEEPCOM;REC=-72,4,F,ASCII;DISC=20,1,1
and then SLEEPERC (the SLEEPER communications program) is run to add entries to
the SLEEPER file. SLEEPERC will ask the date, hour, and minute when the
activity is to start. It will then ask if the activity is to run a program,
stream a job, or execute a command. The name of the proper disc file is asked
for next; then the repetition time in days, hours, and minutes (or 'none') is
requested.
The SLEEPER communication program may be used at any time to add, delete, or
list the current SLEEPER entries; even when the SLEEPER program is running.
(If you are having trouble adding entries, make sure the SLEEPCOM file is not
full.)
After the SLEEPER communication file is set up you may run the SLEEPER program
(either type ':RUN SLEEPER', or let OVERLORD [also from the CSL] run the
SLEEPER program automatically). SLEEPER will then determine the earliest time
that any activity must be executed, then "go to sleep" (via the PAUSE
intrinsic) until it is time to schedule that activity. In this way the SLEEPER
program is little load upon the system, as it is sleeping most of the time.
If a repetition time is specified for an activity then SLEEPER will update the
time to schedule that activity after it has been scheduled by adding the
repetition interval to the scheduling time. If no repetition interval is
specified then that activity is deleted from the communications file after it
is executed.
SLEEPERC is a program used to communicate with the SLEEPER program as it runs.
The OVERLORD program may be used to run SLEEPER or SLEEPER may be run alone
(usually as a batch job).
HOW STREAMX/SLEEPER WORKS
~~~~~~~~~~~~~~~~~~~~~~~~~
As you know, STREAMX gets passwords for job streams by prompting for them at
:STREAM time; but because SLEEPER is streaming the job, there is no one to
answer the passwords. Fortunately, SLEEPER is generally run by MANAGER.SYS (or
a user with SM capability), so STREAMX will automatically generate the
passwords for all job streams streamed by SLEEPER, since STREAMX's logic
dictates that an SM user never needs to answer any passwords because he can
retrieve them anyway.
To link STREAMX with SLEEPER, we need to run STREAMX in immediate mode,
equating the file we want to stream with STRMFILE and invoking STREAMX with
PARM=1.
Unfortunately, SLEEPER cannot run programs with parms, so instead of running
STREAMX, we run STRMSLEP, which simply invokes STREAMX with PARM=1.
LOGOFF -- LOGS OFF INACTIVE SESSIONS
************************************
INTRODUCTION
~~~~~~~~~~~~
Users often log on to the system, do some work, and then leave the terminal
unattended (coffee break?, lunch?) without logging off. Sometimes users even
go home for the day without logging off.
* SECURITY THREAT:
WALK UP TO TERMINAL
TAKE ADVANTAGE OF CAPABILITIES
DISCOVER MPE PASSWORDS TO SENSITIVE ACCOUNTS
This can be a security problem because this means that anyone can come up to a
terminal and use it without having to go through any security system. This can
be an even greater problem if the logged-on user is an Account Manager or the
System Manager because the would-be thief could take advantage of the extra
capabilities and gain access to sensitive information. (It's fortunate,
though, that you are using SECURITY/3000 because the personal profile answers
which must be known to gain access to the system are one-way
encrypted--otherwise, the would-be thief could do a :LISTUSER, :LISTGROUP, and
:LISTACCT, retrieve all the MPE passwords, erase all evidence that he did so by
clearing the screen, and then log on as that user at some later date.
* SYSTEM RESOURCE WASTE:
SYSTEM TABLES
MORE TERMINALS THAN PORTS
Another problem posed by having an idle terminal is that certain system
resources are being used unnecessarily. This can be of particular concern if
you are short on CST and DST entries, and especially if you have several users
contending for a limited number of ports through data switches or port
selectors. Why should an inactive session consume valuable resources?
Logged-on sessions at the end of the day also prevent you from doing your
backup.
LOGOFF remedies these problems. It permits the System Manager to ensure that
any terminal which is logged on but has not been actively used for a certain
length of time is automatically logged off.
HOW LOGOFF WORKS
~~~~~~~~~~~~~~~~
LOGOFF will log off qualifying sessions that have exceeded the acceptable
period of inactivity. You specify how much inactivity is acceptable and which
sessions are to be monitored for inactivity.
* REMOVES INACTIVE/UNWANTED SESSIONS FROM SYSTEM
* INACTIVE = READ PENDING AND NO CPU USAGE RECENTLY
* uses MPE :ABORTJOB #Snnnn
LOGOFF decides that a session is inactive if it's had a terminal read pending
for a long time (at least as long as the configured timeout period). For
example, if the timeout period is 20 minutes (1200 seconds) and some program
prompted the user for input 20 minutes ago and he still hasn't responded,
LOGOFF will abort that user. On the other hand, if the program's been working
for 20 minutes, or even been suspended waiting for a :REPLY (or anything else
that doesn't involve a terminal read), the program won't be aborted.
After you configure LOGOFF (see CONFIGURING LOGOFF in this section) you stream
a job which runs the LOGOFF program--the program will run "in the background"
all the time and monitor the system using a minimal amount of resources.
LOGOFF will perform an :ABORTJOB on inactive sessions--MPE will take care of
file closures, buffer posting, etc.
When a session is aborted by LOGOFF,
* a message saying that the session is being aborted due to lack
of activity is sent to that session's terminal (the text of
this message will default, but you may define your own)
* if the terminal is in BLOCK MODE (e.g. VPLUS screen),
LOGOFF will take the terminal out of this mode and display
its message below the screen.
* a message describing the logoff and identifying the LDEV of
the logged-off session is sent to the system console
* an entry is written to LOGOFF job stream's output
spool file indicating the session number aborted and the time
and date it was aborted
CONFIGURING LOGOFF
~~~~~~~~~~~~~~~~~~
You may configure logoff in a number of ways.
* ACCEPTABLE PERIOD OF INACTIVITY
* WHICH SESSIONS TO MONITOR (BY LDEV)
* SESSIONS CURRENTLY RUNNING PROGRAM
* BLOCK MODE HANDLING
* DS SESSION HANDLING
* ABORT MESSAGE TO BE SENT
First, you must specify the acceptable period of inactivity. This is done with
the $TIMEOUT keyword.
Next, you may optionally configure which sessions will have their activity
monitored by using the $TERMINALS keyword. This is done by defining the
"ldev-pool" of logical devices to be monitored.
Also, you may specify additional criteria to be checked by LOGOFF before the
inactive terminal is aborted (e.g. that sessions running a particular program
should not be aborted).
Furthermore, you may configure how LOGOFF will deal with sessions which have
qualified to be logged off. This includes BLOCK MODE handling, DS SESSION
exclusion, and the MESSAGE to be sent to the user.
If you specify only the $TIMEOUT period, logoff will by default:
* monitor sessions on any logical device
* exit a terminal from block mode and then display message
* not abort sessions with a DS session
* display the default logoff message
* abort sessions running any program
If you have already configured LOGOFF and wish to change something in the
configuration while LOGOFF is running, you need not abort the LOGOFF job and
re-start it--just make the changes to the configuration file and they will take
effect right away (or, rather, the next time the LOGOFF program reads the
LOGOFF data file).
The configuration information for LOGOFF is kept in the file
LOGOFF.DATA.SECURITY and each time you make a change to it by KEEPing the file
from the :EDITOR you must:
:ALTSEC LOGOFF.DATA.SECURITY;(R,X,A,L,W:CR)
SPECIFYING WHICH LOGICAL DEVICES ARE TO BE MONITORED
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may specify which logical devices are to be monitored by LOGOFF. The LDEVs
to be monitored are referred to as the "ldev-pool". This "ldev-pool" is
defined by adding a keyword and a list of LDEVs to the LOGOFF.DATA.SECURITY
file. If you specify to INCLUDE a list of LDEVs, the "ldev-pool" will be that
list of LDEVs. If you specify to EXCLUDE a list of LDEVs, the "ldev-pool" will
be all the LDEVs configured as terminals which are not in your EXCLUDE list.
Either add a line to INCLUDE certain terminals:
$TERMINALS INCLUDE ldev ldev ldev ldev ldev ...
or to EXCLUDE certain terminals:
$TERMINALS EXCLUDE ldev ldev ldev ldev ldev ...
where 'ldev' is any logical device number (e.g. '21 38 40 47') which are
included in or excluded from the logoff "ldev-pool".
LOGOFF will monitor only the sessions logged on to the LDEVs in the logoff
"ldev-pool". The LDEV which is the system console is always excluded from the
"ldev-pool" (even if it is switched from LDEV 20).
If all the LDEVs you need to specify do not fit on a 72-character line, you may
put them on several lines as follows:
$TERMINALS INCLUDE 22 23 24 25 27 29 30 31 32 33 35 37
38 39 47 48 55 56 57 58
If neither a $TERMINALS INCLUDE or $TERMINALS EXCLUDE line is contained in the
file, all LDEVs (except the console and all DS sessions) will be included in
the "ldev-pool". Regardless of what you specify, LOGOFF will only monitor
LDEVs which are configured as type = 16 (terminals).
NOT LOGGING OFF SESSIONS RUNNING A SPECIFIED PROGRAM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After LOGOFF has qualified a session by LDEV and inactivity, you may
additionally specify that sessions running a particular program not be aborted.
This means that programs such as FORMSPEC.PUB.SYS which often have long periods
of inactivity (due to screen design) may be specified to logoff as being
special and that regardless of inactivity this session should not be logged off
while running this program. To configure LOGOFF to EXCLUDE logging off
sessions running a particular program add a line to LOGOFF.DATA.SECURITY:
$PROGRAMS EXCLUDE program program program ...
where 'program's are fully qualified program names (e.g. ENTRY.PUB.SYS
FORMSPEC.PUB.SYS).
If no $PROGRAMS is specified, this check is not performed.
RESTRICTING LOGOFF BY USERS
~~~~~~~~~~~~~~~~~~~~~~~~~~~
With $TERMINALS INCLUDE and EXCLUDE, you can have LOGOFF abort only those
inactive sessions which are running on certain terminals (or, for EXCLUDE,
running on any terminals EXCEPT the ones given). With $PROGRAMS INCLUDE and
EXCLUDE, you can restrict LOGOFF to only look at terminals that are running (or
not running) certain programs. Similarly, with $USERS INCLUDE and EXCLUDE, you
can specify which users should or should not be aborted due to inactivity.
Say, for instance, that you don't mind people walking away from their terminals
whenever they're signed on to non-sensitive accounts. The only accounts that
you really want LOGOFF to work on are AP, GL, and SYS. You can just add the
following line to your LOGOFF.DATA.SECURITY file:
$USERS INCLUDE @.AP @.GL @.SYS
Whenever LOGOFF sees an inactive session, it will check to see if it's logged
on to one of those three accounts; if it isn't, LOGOFF won't touch it.
Similarly, there might be some specific users that you don't want to abort.
BIG.CHEESE, for instance -- your boss -- gets very aggravated when he gets
kicked off the system, and the fact that he shouldn't leave his terminal
inactive doesn't sway him. Rank has its privileges, after all, and you can
just say
$USERS EXCLUDE BIG.CHEESE
Actually, you can be very specific in who you include or exclude. As the first
example above showed, you can specify user identifiers with wildcards (@.AP,
CLERK@.GL, JOE.@, etc.); also, you can select by session name and group name as
well as user name and account name, so you can say
$USERS EXCLUDE JOE,@.DEV,SOURCE
which will exclude sessions signed on with session name "JOE" into the "SOURCE"
group of the "DEV" account.
If you have neither a $USERS INCLUDE nor a $USERS EXCLUDE line in the
LOGOFF.DATA.SECURITY file, LOGOFF will abort inactive sessions regardless of
their user id (although the $TERMINALS and $PROGRAMS restrictions still apply).
This is a pretty good default, since usually any inactive session is not a good
thing to have around.
DS SESSIONS - TO ABORT OR NOT TO ABORT (THAT IS THE OPTION)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LOGOFF may be configured to abort sessions regardless of whether they are a
local or remote DS-session. By default, LOGOFF will not abort any DS-session.
You may perform the abort by configuring the LOGOFF.DATA.SECURITY file with the
keyword:
$DSABORT
This will cause DS-sessions to be aborted.
SAMPLE CONFIGURATION
~~~~~~~~~~~~~~~~~~~~
EXAMPLE1: If the LOGOFF.DATA.SECURITY file contained the following:
$TIMEOUT 900
$TERMINALS EXCLUDE 33 36 38 39 45
$PROGRAMS EXCLUDE FORMSPEC.PUB.SYS ENTRY.PUB.SYS
then LOGOFF would abort all sessions that were all of the following:
Inactive for more than 900 seconds (15 minutes)
AND logged on to an LDEV other than 33,36,38,39 or 45
AND running a program other than FORMSPEC.PUB.SYS and ENTRY.PUB.SYS
EXAMPLE2: If the LOGOFF.DATA.SECURITY file contained the following:
$TIMEOUT 1200
$TERMINALS INCLUDE 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
48 49 50 51 52 53 54 55 56 57 58 59 60
then LOGOFF would abort all sessions that were:
Inactive for more than 1200 seconds (20 minutes)
AND logged on to an LDEV from 33 to 60 inclusive.
ACTIVATING LOGOFF
~~~~~~~~~~~~~~~~~
To have LOGOFF continually monitor the system and abort idle sessions (using
the parameters you have configured in LOGOFF.DATA.SECURITY) you need to stream
a job which runs the LOGOFF.PUB.SECURITY program, which wakes up every so often
(using a minimal amount of system resources) and aborts all sessions which
should be aborted, according to your configuration in LOGOFF.DATA.SECURITY.
The logoff job stream is stored in the file
LOGOFF.JOB.SECURITY
which does not contain any passwords on the job card, so STREAMX should be used
to stream the job (see the "STREAMX" section of this manual for information
about eliminating passwords in job streams). Just do this:
:FILE STRMFILE=LOGOFF.JOB.SECURITY
:RUN STREAMX.PUB.SECURITY;PARM=1
STOPPING LOGOFF
~~~~~~~~~~~~~~~
"A car needs to be able to do only two things -- to go and to stop."
A LOGOFF job stream is just a 'plain vanilla' MPE job. If you want to abort
it, you can just do an :ABORTJOB, just like you would for any job of your own.
On the other hand, MPE's :ABORTJOB is sometimes rather temperamental. Surely
you, as a system manager, have often encountered sessions that just won't go
away -- no matter how many :ABORTJOBs are done, they're still there; sometimes
you even have to re-start the system if you want them removed.
This is why it's a good idea for all background tasks, like LOGOFF, to have
some normal shutdown procedure, which can let somebody stop them without having
to do an :ABORTJOB. To do this, you just
:RUN LOGOFF.PUB.SECURITY,STOP
This will send a message to the LOGOFF job stream using a message file; LOGOFF
will catch this message and perform an orderly shutdown of itself. Of course,
you can still do an :ABORTJOB of the job stream if you want to, but we think
that the ":RUN LOGOFF.PUB.SECURITY,STOP" is a cleaner solution.
Note that there's no reason why you have to abort the LOGOFF job stream when
you do a system backup. Just keep it running.
PASCHG-changing MPE passwords
*****************************
INTRODUCTION
~~~~~~~~~~~~
To protect the security of their systems, many installations encourage (or
require) MPE passwords to be changed periodically. That way, by the time a
password gets out over the "grapevine," it will have been changed.
Unfortunately, MPE's security system makes changing user passwords rather
difficult. Since only an Account Manager--not the user himself!--can change a
user password, changing passwords is actually discouraged. A user may feel
reluctant to spend time getting in touch with his Account Manager about
changing a password (even if he, the user, suspects it has been compromised);
an Account Manager is very likely to put off changing passwords if it means
changing them for 100 users in his account.
A very good solution to this problem--in fact, one implemented on most other
computer systems--is to allow a user to change his own password. Since the
user is allowed to change only his own password (not other users'), this poses
no security threat; in fact, it actually improves security by making it easier
for a user to get his own password changed.
HOW PASCHG WORKS
~~~~~~~~~~~~~~~~
A user may run the PASCHG program, which first prompts him for his current MPE
user password (if he has one). The user must enter the correct password in
order to change it--this protects against somebody walking up to a logged-on
terminal while its real user is away and changing the password (although
SECURITY/3000's LOGOFF program is a better solution to this problem.
After the user has correctly entered his current password, he is asked for a
new password. After he enters the new password, he is asked to enter the same
password again, to make sure that he did not enter it incorrectly the first
time. If he enters a different password the second time, PASCHG assumes that
he has made a typo and repeats the new password sequence.
Once the user has entered a new password (and entered the same password again,
guaranteeing that it's the one he really wants), his password is changed.
A user is not allowed to use PASCHG to remove his own password, since the
Account Manager might often want to require his users to have passwords;
therefore, if the user hits <return> when asked for the new password, an error
message will be printed and the password will remain unchanged.
PASCHG also forbids a user from changing his password to the same value, as
that would defeat the purpose of changing the password.
HOW TO SET UP PASCHG
~~~~~~~~~~~~~~~~~~~~
The PASCHG program is
PASCHG.PUB.SECURITY
Any user may :RUN it, and the easiest way to do this is to set up the UDC
"PASCHG" so that a user may type just one word to invoke the program.
We recommend that you set the PASCHG UDC at the system level so that all users
may run it:
:SETCATALOG CHGUDC.PUB.SECURITY, YOURUDCS.PUB.SYS; SYSTEM
That way, a user need merely type
:PASCHG
and the PASCHG system will be invoked.
Certainly, there are some HP3000 installations whose security systems operate
in such a way that they don't want users changing their own passwords. A good
example of this is when several people share a single user ID, and you don't
want one of them to change their joint password (although for this kind of
application, SECURITY/3000's security-by-session-name should be used.
If you don't want your people running PASCHG.PUB.SECURITY, simply put a
lockword on this file or remove it entirely from the system. No other part of
SECURITY/3000 depends on it, so all the other components of SECURITY/3000 --
the Logon Security System, LOGOFF, OBSOL, TERMPASS, STREAMX, etc. -- will
still function as well as always.
EXAMPLE OF A PASCHG SESSION
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A typical session with PASCHG might look like:
:PASCHG << a UDC that runs PASCHG.PUB.SECURITY >>
SECURITY/PASCHG Version 0.2 (VESOFT, Inc. (C) 1985)
Please enter your current user password: << user enters it >>
Please enter your new user password: << user enters 'FOO' >>
Please enter the same password again: << 'FOO' again >>
Password changed.
Note that none of the password inputs are echoed; furthermore, if the user
wanted to abort the change any time until he entered the new password the
second time, he could do so by hitting <control-Y>.
PASCHG/OBSOL INTERFACE
~~~~~~~~~~~~~~~~~~~~~~
PASCHG works well with OBSOL, SECURITY/3000's MPE Password Obsolescence System
since with PASCHG the Account Manager isn't burdened with having to change
dozens of passwords at the end of every month. However, in order for OBSOL to
"know" that a password has been changed with PASCHG, PASCHG has to be told to
tell OBSOL that a change is being made.
If you run PASCHG.PUB.SECURITY with ;PARM=1, it will invoke OBSOL and tell it
that the password is being changed.
So if you use OBSOL, your :PASCHG UDC ought to look like:
PASCHG
RUN PASCHG.PUB.SECURITY;PARM=1
(whereas if you don't use OBSOL, the ';PARM=1' should be omitted). In fact,
the OBSUDC.PUB.SECURITY UDC file, which contains all the UDCs relevant to
OBSOL, contains this PASCHG UDC as well.
Note that when a user changes his own password, he is not allowed to change the
obsolescence period and warning period (as is normally the case when an Account
Manager changes a user's password). This is done because the Account Manager
might not want users altering the obsolescence period, perhaps lengthening it
to the point where passwords no longer have to be changed frequently.
Note: you may configure OBSOL to run PASCHG automatically when the user
password is within its warning period (see OBSOL).
In addition, PASCHG may be invoked automatically from OBSOL so that if a user
logs on and is warned that his password will expire, PASCHG will be run
automatically to permit the user to change his password at that time. This can
further automate the process of password maintenance because a user does not
have to know what program to run, what UDC name to type, or whom to contact to
get his password changed.
The following UDC may be used instead of OBSOLUDC to invoke the OBSOL system.
As you can see, OBSOL will set a JCW which the UDC recognizes to run the PASCHG
program. This UDC is stored as the file OBCHGUDC.PUB.SECURITY.
OBSLOGON
OPTION LOGON, NOBREAK
RUN OBSLOG.PUB.SECURITY
IF SECURITYANSWER = 1 THEN
BYE
ELSE
IF CHGUSERPASS = 1 THEN
RUN PASCHG.PUB.SECURITY;PARM=1
ENDIF
ENDIF
ENFORCING PASSWORD STANDARDS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You may configure PASCHG to edit passwords that your users specify for
themselves. This editing may be used to enforce minimum password length in
addition to specific alpha, alphanumeric and numeric character patterns. The
edit characters used are similar to COBOL's. The 'edit pattern' is specified
by adding a line to the file SECURMGR.PUB.SECURITY in the format:
PASCHG-EDIT=<edit pattern>
Where the <edit pattern> conforms to the following rules:
'X' is any alphabetic [a..z] or numeric [0..9]
'A' is any alphabetic character
'9' is any numeric character
For example:
PASCHG-EDIT=AXXX enforces 4 character minimum password length
PASCHG-EDIT=AXXX9 enforces 5 character minimum password length
one alpha, three alphanumeric, one numeric
PASCHG-EDIT=AAAAAAAA enforces 8 character minimum password length
all alpha
Regardless of what is specified by PASCHG-EDIT, as per valid MPE password
format, the first character of the edit pattern will be assumed to be an 'A'
(alpha) when editing the password input. If the new password is longer than
the edit pattern specified in SECURMGR.PUB.SECURITY, those characters are not
edited.
If no PASCHG-EDIT keyword is found in the SECURMGR.PUB.SECURITY
file, PASCHG will use the default edit
pattern of 'AXXX' indicating a
minimum four character password.
GETPASS: A PROCEDURE TO GET ONE'S OWN PASSWORD
**********************************************
INTRODUCTION
~~~~~~~~~~~~
There is an unfortunate deficiency in MPE which forbids a user from retrieving
his own passwords; this necessitates programmers who are building and
:STREAMing streams from inside their programs to embed passwords into those
programs, which makes the necessary (mandatory?) operation of changing
passwords once in a while simply unfeasible. The user-callable procedure
GETPASS is designed to remedy this state with it, any user is allowed to
retrieve his own passwords (which is certainly not a security threat, as he
needed to know them to sign on; also, for convenience, the system manager is
allowed to retrieve the passwords of ANYBODY (for he is god anyway), and the
account manager may retrieve the passwords of anybody in his account. Thus,
with GETPASS a programmer can call WHO, find out his user, group, and account
names, call GETPASS, and retrieve his passwords; then, it is easy to insert
these passwords into the job card. Thus,a hard-to-maintain embedded passwords
can be avoided.
GETPASS has the following parameters:
PARAMETER 1: USER - The user to get passwords for.
2: ACCOUNT - The account to get passwords for.
3: GROUP - The group to get passwords for.
4: PASS-USER - The user password.
5: PASS-ACCT - The account password.
6: PASS-GROUP- The group password.
7: ERR - FALSE = everything went OK; TRUE = security
violation or nonexistent user, account,
or group.
GETPASS needs to use privileged mode (PM) capability for its execution;
however, it uses it in a safe fashion and has NEVER caused a system failure
yet! Note that programs calling GETPASS need not be PREPed with PM capability;
it must reside in an SL in a group and account containing PM capability (like
SL.PUB.SYS). To add GETPASS to the system SL, you need merely do a CP\INDEX
GETPASS.PUB.SECURITY
:HELLO MANAGER.SYS
:SEGMENTER VX
-SL SL Z@
-USL GETPASS.PUB.SECURITY
-ADDSL GETPASS
-EXIT
GETPASS can be called from COBOL in the following way:
USER PIC X(8).
ACCOUNT PIC X(8).
GROUP PIC X(8).
PASS-USER PIC X(8).
PASS-ACCOUNT PIC X(8).
PASS-GROUP PIC X(8).
ERROR PIC S9(4) COMP.
.
..
CALL "GETPASS" USING USER, ACCOUNT, GROUP, PASS-USER, PASS-ACCOUNT,
PASS-GROUP,ERROR.
IF ERROR IS NOT EQUAL TO 0 THEN << An error occurred >>
DISPLAY "SECURITY VIOLATION OR BAD USER, ACCOUNT, OR GROUP"
STOP RUN.
A real live example of a FORTRAN program calling GETPASS:
$CONTROL NOSOURCE, USLINIT
PROGRAM TEST GETPASS
INTEGER USER(4), ACCT(4), GRUP(4), UPAS(4), APAS(4), GPAS(4)
CHARACTER *8 BUSER, BACCT, BGRUP, BUPAS, BAPAS, BGPAS
EQUIVALENCE (BUSER,USER),(BACCT,ACCT),(BGRUP,GRUP), (BUPAS,UPAS),(BAPAS,
APAS),(BGPAS,GPAS)LOGICAL ERR
DISPLAY "ENTER USER: "
ACCEPT BUSER
DISPLAY "ENTER ACCOUNT: "
ACCEPT BACCT
DISPLAY "ENTER GROUP: "
ACCEPT BGRUP
CALL GETPASS (USER, ACCT, GRUP, UPAS, APAS, GPAS, ERR)
IF (ERR) DISPLAY "ERROR: SECURITY VIOLATION/BAD PARAMETER"
IF (ERR) GOTO 10
DISPLAY "USER PASSWORD=",BUPAS
DISPLAY "ACCOUNT PASSWORD=",BAPA
DISPLAY "GROUP PASSWORD=",BGPAS
10 STOP
END
FILES IN THE SECURITY ACCOUNT
*****************************
INTRODUCTION
~~~~~~~~~~~~
Lastly, I want to list some things you may see in your explorations. There are
many interesting files to be found withing the SECURITY account. Here is a
list and description of the common file you may find there:
DATA group: Data files
~~~~~~~~~~~~~~~~~~~~~~~
ANSSCHEM - Schema of the database ANSWER (might be used to increase
database capacity; default is 500 records).
ANSWER - IMAGE database which contains information about PERSONAL
PROFILE LOGON IDs (one-way encrypted passwords, access
restrictions, menu file names, etc.).
LOG - Circular disc file to which all attempted security
violations and security configuration changes are logged.
LOGOFF - Specifies logical devices to be monitored and the length
of inactivity required prior to a session being aborted.
MEMOFORM - Memo format for attempted violation listings which may be
customized to provide more or less detail.
OBSSCHEM - Dbschema input file for the image database OBSOL.
OBSOL - IMAGE database specifying the date by which MPE GROUP, USER
and ACCOUNT passwords must be changed (warning period, too).
QUESTION - During SECURITY/3000 logon the user must answer a question
randomly selected from this file (built by user; personal
profile questions are recommended).
TERMPASS - Specifies logical devices which will be protected with
passwords. Protection for dial-ups, DS lines, etc.
DOC group: Documentation files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ANORDER - Contains the DOC file names in the order in which they
should be printed.
CONTENTS - Table of contents for the SECURITY/3000 manual.
FILES - Describes the files in the SECURITY account.
GETPASS - Explains how to build job stream file in application
programs without jeopardizing system security.
HOW2LIST - Describes how to print the documentation files provided
in the DOC group with the MPEX 'USER' command.
INTRO - Overview of SECURITY/3000 package.
LOGOFF - Explains why idle sessions are a security threat. Step
by step instructions of how to configure logoff.
NEWFEATR - New features in SECURITY/3000.
OBSOL - Describes how the password obsolescence subsystem insures
the frequent changing of MPE passwords.
ONLINE - Describes the Logon Security System which protects against
online logon access.
PASCHG - User (not account manager) changeable passwords.
REFS - List of SECURITY/3000 published references.
STREAMX - Manual for STREAMX/3000 which provides batch access
security and parameter passing to job streams.
TERMPASS - Documentation of TERMPASS, which allows protection of
logical devices (DS line, dial-in lines, console, etc).
HELP group
~~~~~~~~~~
HELPMAKE - The stream to modify USER.HELP.SECURITY file.
USER - The HELP file for SECURITY/3000.
JOB group: Job streams
~~~~~~~~~~~~~~~~~~~~~~~~
LOGOFF - Job stream which runs the program LOGOFF.PUB to monitor
sessions' CPU usage and logoff idle terminals by LDEV.
PAPERS group: Security-related papers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ANAHEIM - "BURN BEFORE READING - HP 3000 SECURITY AND YOU",
HPIUG 1983, Anaheim, CA USA.
COPNHAGN - "SECURITY/3000: A new approach to logon security",
HPIUG 1982, Copenhagen, DENMARK.
PROFILE - "PRODUCT PROFILE: SECURITY/3000",
SUPERGROUP Association Newsletter, July 1982.
PUB group: Program files, USLs, UDCs, etc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FINDCAP - A program to list dangerously capabilitied users and show
if they have an MPE password. QUITE handy...
LOGOFF - Program which logs off idle sessions.
OBSCHG - Password OBSOLescence database update program.
OBSFILL - OBSOLescence data base initialization program.
OBSLOG - MPE passwords obsolescence program.
OBSOLUDC - Log-on UDC file for MPE passwords obsolescence subsystem.
OBSUDC - UDC file for MPE passwords obsolescence subsystem.
PASCHG - The program which lets users change their own password.
QGALLEY - Program to format and print DOC files.
SECURMGR - Control file containing SECURITY/3000 global parameters.
SECURUDC - Log-on UDC file for users protected by SECURITY/3000.
SECURUSL - USL file for the callable SECURITY procedure.
SESSION - USL file for GETSESSION procedure.
STREAMX - STREAMX/3000 program which provides batch access
security and parameter passing to job streams.
STRMSLEP - The SLEEPER/STREAMX interface program (see STREAMX.DOC).
STRMUDC - UDC file containing a UDC to invoke STREAMX.
TERMPASS - Program which verifies terminal (LDEV) passwords and/or
interfaces with USER program for positive user identification
TERMUDC - Log-on UDC file for users using TERMPASS.
USER - The main SECURITY/3000 program.
Back to the master Table of Contents.