BURN BEFORE READING - HP3000 SECURITY AND YOU
by Eugene Volokh, VESOFT
Presented at 1984 HPIUG Conference, Anaheim, CA, USA
Published in "Thoughts & Discourses on HP3000 Software", 1st-4th ed.
DISCLAIMER
One of the most important things you can do for your security system
is to plug holes that may exist in it. To help you do this, this paper
shows some ways in which most inadequately secured systems can be
penetrated. Although this information can be used by would-be security
violators to break into a poorly secured system, it is in my opinion
more important that it can be used by you to protect yourself against
these violators.
ATTENTION WOULD-BE THIEVES! DO NOT READ ANY FURTHER!
INTRODUCTION
Life's not fair.
Just when you think you've got it made, just when you (or your
company) have found the pot of gold at the end of the rainbow, you
find it out.
Someone else wants the same pot.
SECURITY
To prevent your property from becoming theirs, you set up a series of
obstacles between the would-be thief and your property. It is these
obstacles that comprise your security system, and it is the quality of
these obstacles that determines whether or not your property (in our
case, your computer data) is secure.
These obstacles come in two flavors:
* Obstacles to unauthorized retrieval of data. Data is often
valuable in and of itself, whether it is salary information you
want to keep secret from your employees, financial information you
want to keep secret from your competition, or military information
you want to keep secret from THEM.
* Obstacles to unauthorized modification of data. Data does not
exist for its own sake; real-life decisions are made based on that
data, and unauthorized modification of data can affect those
decisions in an undesirable way.
This paper will try to give you some useful tips on making your
valuable data more secure.
THE ROAD TO YOUR DATA
Consider Joe Q. Sinister, who has his sights set on your payroll
database. There is a fixed road that he must travel to reach the data
stored in it and change it; knowing this road will help us erect the
proper roadblocks.
His first step must be to log on to the computer; if we can frustrate
his attempts to do that, our data is secure. The techniques used to
prevent unauthorized users from logging on to the computer are called
LOGON SECURITY.
LOGON SECURITY
Logon security is probably the most important component of your
security fence. This is because many of the subsequent security
devices (e.g. file security) use information that is established at
logon time, such as user id and account name. Thus, we must not only
forbid unauthorized users from logging on, but must also ensure that
even an authorized user can only log on to his user id.
So, logon security essentially involves ensuring that the person
logging on is authorized to use the user id he is logging on to. How
is this to be done?
The optimal approach, of course, would be to somehow identify who the
person is (fingerprints? retina scan?) and check to see if he is on
the authorization list for the particular user id. Unfortunately,
these approaches are not within the means of most HP3000 users;
however, another good method is.
A person can be identified by what he knows almost as well as by what
he looks like. For instance, a user id may be assigned a password, and
only the people authorized to use that user id may be told that
password. Then (assuming no one else somehow learns the password), if
a person knows the password, it follows that he is authorized.
Alternatively, if one and only one user is allowed to use a particular
user id, he may be asked to enter some personal information (mother's
maiden name?) when he is initially added to the system, and then be
asked that question (or one of a number of such personal questions)
every time he logs on. This general method of determining a user's
authorizations by what he knows we will call "knowledge security."
Unfortunately, the knowledge security approach, although one of the
best available, has one major flaw -- unlike fingerprints, information
is easily transferred, be it revealed voluntarily or involuntarily;
thus, someone who is not authorized to use a particular user id may
nonetheless find out the user's password. You may say: "Well, we
change the passwords every month, so that's not a problem." The very
fact that you have to change the passwords every month means that they
tend to get out through the grapevine! A good security system does not
need to be redone every month, especially since that would mean that
-- at least toward the end of the month -- the system is already
rather shaky and subject to penetration.
Ironically, the biggest culprit in this respect is the user himself.
Users have often been known to write down passwords and post them in
prominent places so they will not forget them; reveal passwords to
people who really shouldn't know them; and, in general, wreak havoc on
your logon security system. Some methods have been designed to cope
with this, such as the personal profile security system (asking
questions such as "What's your mother's maiden name?," "Where did you
go on your first date?," etc.) described above, whose main advantage
is that users are less likely to reveal personal data than impersonal
passwords; additionally, there can be more than one personal profile
password -- several of them or a random one can be asked at logon time
-- whereas the alternative is user password only. However, the user is
still the weakest link in the logon security system, and major steps
should be taken to avoid voluntary password disclosure by the user.
Thus, an important security rule arises:
* THE USER IS THE WEAKEST LINK IN THE LOGON SECURITY SYSTEM --
DISCOURAGE HIM FROM REVEALING PASSWORDS (by techniques such as
personal profile security or even by reprimanding people who
reveal passwords -- they seem innocent, but they can lose you
millions).
Yet another way in which passwords are often revealed is by having job
streams with embedded passwords. First of all, unless you take special
precautions (such as altering the job streams so that Read access to
them is disallowed, and only Execute -- enough for :STREAMing -- is
permitted), anyone who can stream the job stream can also read it and
thus see the passwords; in any case, any listing of the job stream (of
which plenty are liable to be laying around the computer room)
contains this password. More importantly, since changing a password
means having to change every single job stream that contains it, these
passwords are virtually guaranteed never to be changed. Fortunately,
there is a simple way to resolve this problem: there are plenty of
programs, contributed and vendor-supported, that take a job stream
without embedded passwords, prompt for them, insert them into the job
stream, and then stream it.
* PASSWORDS EMBEDDED IN JOB STREAMS ARE EASY TO SEE AND VIRTUALLY
IMPOSSIBLE TO CHANGE -- AVOID THEM.
Another way of increasing logon security is by indirectly using
another aspect of user identification -- identification by human
beings. Actually, this could be the main part of your logon security
system: any user who wishes to sign on must first get clearance from a
security guard or console operator. Going quite this far is too
expensive, but a little bit of this can be obtained for free.
If some 15-year-old high school student walks into your data entry
area and starts using the computer, people are bound to notice. It is
fear of being identified as a security violator by other human beings
that causes most violation attempts to come across phone lines,
usually at night or on weekends. Thus, another useful security feature
is to be able to restrict access by access location (i.e. terminal)
and access time. The very fact that someone is trying to run payroll
across a phone line at 11 P.M. on a Saturday is an indication of
unauthorized access. Thus, it is worthwhile to implement some form of
security that prohibits access to certain user id's and accounts at
certain times of day, days of week, and/or from certain terminals.
Alternatively, you might want to force people to answer an additional
password at certain times, or especially when signing on from certain
terminals.
This may seem like a poor approach indeed -- after all, if the thief
hits the time of day, day of week, or terminal prohibition/password,
this means that he has successfully penetrated the rest of your
security system, which will never happen -- right? In reality, this is
a very potent way of frustrating would-be security violators,
especially if the attempted violators are promptly investigated. Thus,
another maxim appears:
* SOME FORMS OF ACCESS ARE INHERENTLY SUSPECT (AND THEREFORE REQUIRE
EXTRA PASSWORDS) OR ARE INHERENTLY SECURITY VIOLATIONS. THUS,
ACCESS TO CERTAIN USER ID'S AT CERTAIN TIMES OF DAY, ON CERTAIN
DAYS OF THE WEEK, AND/OR FROM CERTAIN TERMINALS (SUCH AS DIAL-IN
OR DS LINES) SHOULD BE SPECIALLY RESTRICTED.
ASIDE -- ATTEMPTED VIOLATION REPORTING
Before we go any further with our discussion of various security
devices, it is worthwhile to pay particularly close attention to
something which should be present in all security devices -- violation
reporting.
No security system can cover you 100% -- given enough time, a
determined (or even relatively casual) thief can penetrate even the
best system. Fortunately, before this one successful penetration,
chances are that the thief will make many unsuccessful attempts; if
you pay attention to these unsuccessful attempts, you can catch the
thief (or at least improve the security system by, say, temporarily
shutting down dial-in lines) before he gets in.
This may seem obvious, but few shops really pay attention to
unsuccessful penetration attempts -- when was the last time you looked
at "INVALID PASSWORD" messages on the system console or in the log
files? In reality, every incorrect password entry is an indication of
a possible attempted security violation, even more so if there are
several such errors in a row.
HP doesn't help any either -- the INVALID PASSWORD messages look just
like any other console message (no enhancements of any kind); the only
place where invalid password entries are logged are in the system log
files together with the rest of the console log messages. It would be
far more desirable to have the message logged to a separate log file,
and maybe even reported to the line printer or some special device.
Additionally, it might be wise for a terminal on which an invalid
password entry occurs to be shut down for some period of time so that
it would take more time for a would-be thief to try more passwords.
But, even with the existing HP system, an alert console operator can
nip many a potential security violation in the bud by catching the
INVALID PASSWORD messages that can be a sign of an attempted
violation. In fact, there is a way to highlight some messages so they
will be more easily visible. Since most MPE messages are stored in the
system file called CATALOG.PUB.SYS, you can do the following:
1. Sign on as MANAGER.SYS.
2. In EDITOR (or TDP), /TEXT CATALOG.PUB.SYS
3. Modify the first line in the file that starts with "65 " and the
first line that starts with "68 " to contain an escape sequence
such as "escape&dB" (inverse video) right after the blank after the
message number and to contain a "escape&d@" (turn off enhancement)
at the end of the message. Alternatively, if you have a 263x with
expanded character set, insert an "escape&k1S" (enter expanded set)
right after the blank after the message number and a "escape&k0S"
(exit expanded set) at the end of the message. Similar escape
sequences may be put in if you have some other kind of terminal or
a voice output device.
4. /KEEP the file as INPUT.
5. :RUN MAKECAT.PUB.SYS,BUILD
6. Presto! Your "INVALID PASSWORD" and "MISSING PASSWORD" messages
are now much easier to read.
Thus:
* MANY SECURITY VIOLATIONS CAN BE AVERTED BY MONITORING THE WARNINGS
OF UNSUCCESSFUL VIOLATION ATTEMPTS THAT OFTEN PRECEDE A SUCCESSFUL
ATTEMPT. IF POSSIBLE, CHANGE THE USUAL MPE CONSOLE MESSAGES SO
THEY WILL BE MORE VISIBLE.
LOGOFF SECURITY
Another threat to your system security is, unfortunately, a rather
common one. If someone signs on to a terminal and then walks away
(perhaps for a lunch break), a would-be thief can access your computer
without even having to log on -- he can just walk up to the terminal
and use it.
You may think this to be a relatively rare occurrence, but consider:
do your people always sign off when they go to lunch? Haven't there
been times when they forgot to sign off even before they leave for the
day? Leaving a terminal signed on is a very common mistake, and one
that can greatly jeopardize the security of your system.
How can you solve this problem? Well, for one, you can tell your
people to sign off whenever they leave the terminal. Alternatively, if
you find that people often leave the terminal when it's in some
particular state (say, the main menu of your accounts payable
program), set a timeout just before issuing the terminal read (with
the FCONTROL intrinsic, mode 4). That way, when the user does not
respond for a certain amount of time, the read will abort, and your
program will be able to terminate and maybe log the user off. Even
better alternative is to use a contributed or vendor-supplied program
that automatically aborts all terminals that have been inactive for
more than a certain amount of time (such as Boeing's BOUNCER or
VESOFT's LOGOFF).
Another, more dangerous, problem occurs when a dial-in user hangs the
phone up instead of properly :BYEing off. Then, if the dial-in line is
configured with subtype 0, the user will not be automatically :BYEd
off, and the next person to call up the computer will be dropped into
the still-logged-in session. Thus, remember to configure all your
dial-in lines with subtype 1 or tell your users under no uncertain
terms that they MUST always :BYE off when using the dial-in line.
Thus,
* LEAVING A TERMINAL LOGGED ON AND UNATTENDED IS JUST AS MUCH OF A
SECURITY VIOLATION AS REVEALING THE LOGON PASSWORD. USE SOME KIND
OF TIMEOUT FACILITY TO ENSURE THAT TERMINALS DON'T REMAIN INACTIVE
FOR LONG; SET UP ALL YOUR DIAL-IN TERMINALS WITH SUBTYPE 1.
RESTRICTED VS. UNRESTRICTED USER INTERFACE
As was mentioned before, logon security is a very important component
of your security system, but it is by no means the only one. Many
security violations are committed by people who are allowed to sign on
to the computer but who manage to get at things that they are not
permitted to access.
There are two major ways of prohibiting authorized users from doing
unauthorized things. One is by permitting them to do only certain
specific things (the inclusive approach) and the other is by
forbidding them from doing specific things (the exclusive approach).
Each has its merits, its uses, and its security strategies.
THE INCLUSIVE APPROACH
Briefly, the inclusive approach is usually implemented by having an
OPTION LOGON, NOBREAK (the NOBREAK is important!) UDC that runs an
application program and then, upon exit from the program, immediately
BYEs. Thus, the user is only allowed to perform the function or
functions of this one program (or, if the program so wishes, only a
subset of these functions), and he is forbidden from doing anything
else -- accessing files, running programs, or executing MPE commands.
This is, overall, a good approach. Its only real problem is that in
some instances it is too restrictive -- some users (especially
programmers) need to have access to the entire power of MPE. However,
when the user does not need to access MPE, it is not only more secure
but it is also more convenient for the user to be automatically
dropped into his program when he signs on and to be automatically
signed off when he exits the program. However, certain technical
issues must be kept in mind:
1. Don't forget to make the UDC OPTION LOGON, NOBREAK. If you omit the
NOBREAK, the user can hit break, type :ABORT, and get into MPE.
2. A lesser-known fact is that it is usually essential that you add a
CONTINUE line before running your program, thus making your UDC
look something like
LOGONUDC
OPTION LOGON, NOBREAK
CONTINUE
RUN ACCPAY.PUB.AP
BYE
Why? Because otherwise, if the program aborts, the entire UDC will
be flushed and the BYE will never be encountered. Although it might
seem quite improbable that your program will abort, the user can
actually make most programs abort by typing a :EOD (or sometimes
just a :) when prompted for input. This causes an end of file on
$STDIN and makes many programs, including almost all BASIC, COBOL,
FORTRAN, and PASCAL programs, abort.
Of course, this approach need not be restricted to running simple
applications programs. One of the best uses of this approach is to run
a program that displays a menu of allowed MPE commands or constructs
and asks the user to choose one. Thus, if you want a user to access
the A/P system, EDITOR, or the TELLOP command, you might write a
program that displays these three options to the user, asks the user
for one, and then executes it (via the COMMAND or CREATE intrinsic).
Even better, get a general-purpose menu processing program that
permits you to easily set up various menus by just changing some data
files. Thus,
* A USEFUL APPROACH TO SECURING YOUR SYSTEM IS TO SET UP A LOGON
MENU WHICH ALLOWS THE USER TO CHOOSE ONE OF SEVERAL OPTIONS RATHER
THAN TO LET THE USER ACCESS MPE AND ALL ITS POWER DIRECTLY.
THE EXCLUSIVE APPROACH
Sometimes, programmers or other users that have to use a wide range of
programs, files, and MPE commands must have access to MPE itself. This
is a far less controlled environment than a program that is run at
logon time, but can still be secured very well.
One approach to securing the system while still allowing people to
access MPE is to disable certain MPE commands you find do not want to
be executed. For instance, say you do not want your people to :STREAM
jobs. You could set up a system or account UDC
STREAM !FILENAME="$STDIN", !COLON="!"
OPTION LIST
COMMENT YOU ARE NOT ALLOWED TO :STREAM FILES.
That way, whenever someone types a :STREAM command, he gets the UDC
instead.
This approach, however, has a major flaw: although the command
interpreter gives precedence to UDCs over ordinary MPE commands (thus
allowing you to block out :STREAM commands by setting up a STREAM
UDC), the COMMAND intrinsic does not. Thus, if the user is allowed to
access FCOPY, EDITOR, TDP, SPOOK, or even a user-written program that
calls the COMMAND intrinsic, he will be able to bypass the UDC
restriction. In other words, in the example above, all I need do to
bypass the :STREAM command restriction is to run FCOPY, and type the
:STREAM command from there!
The only exceptions to the above rule are the commands that cannot be
directly executed via the COMMAND intrinsic, such as :RUN, :PREP,
compiler commands, :SETCATALOG, and :SHOWCATALOG. But even these
commands (all except :SETCATALOG and :SHOWCATALOG) are available
through some programs, such as TDP and SPOOK.
Thus,
* BLOCKING OUT MPE COMMANDS VIA UDC'S WITH THE SAME NAME WILL
USUALLY FAIL UNLESS THE COMMAND IS :SETCATALOG OR :SHOWCATALOG OR
IF YOU ALSO FORBID ACCESS TO MANY HP SUBSYSTEMS AND HP-SUPPLIED
PROGRAMS. THIS SEVERELY LIMITS THE USEFULNESS OF THIS METHOD.
Again, I'd like to stress that the :SETCATALOG and :SHOWCATALOG can be
blocked out this way, as can (with more difficulty) the :RUN command
and some other commands; however, the set of commands still permitted
will usually be so small, the method involved so complex, and the
chance of penetration so great, that all advantages of the exclusive
approach pale in comparison.
By far the best way, in my opinion, of implementing the exclusive
approach is by using the existing MPE file, database, and program
security features, which is what the next few sections will discuss.
FILE SECURITY
File security is quite possibly the most sophisticated and the least
used and understood security system provided by MPE. If properly
handled, it can permit a user to use all MPE commands and all of MPE's
power without allowing him to go beyond the confines of his files.
Each file has a so-called "security matrix," an array of information
that describes what classes of users can read, write, append, execute,
and/or lock a file. Similarly, each group has a security matrix
describing the security to be set for its files, and each account also
has a security matrix. These security matrices are what LISTDIR2 shows
you when you do a LISTSEC (or LISTF, LISTGROUP, or LISTACCT).
When a user tries to open a file, MPE checks the account security
matrix, the group security matrix, and the file security matrix to see
if the user is allowed to access the file. If he is allowed by all
three, the file is opened; if at least one security matrix forbids
access by this user, the open fails. For instance, if we try to open
TESTFILE.JOHN.DEV when logged on to an account other than DEV and the
security matrix of the group JOHN.DEV forbids access by users of other
accounts, the open will fail (even though both TESTFILE's and DEV's
security matrices permit access by users of other accounts).
Each security matrix describes which of the following classes can
READ, WRITE, EXECUTE, APPEND to, and LOCK the file:
* CR - File's creator
* GU - Any user logged on to the same group as the file is in
* GL - User logged on to the same group as the file is in and having
Group Librarian (GL) capability
* AC - Any user logged on to the same account as the file is in
* AL - User logged on to the same account as the file is in and having
Account Librarian (AL) capability
* ANY - any user
* Any combination of the above (including none of the above)
By default, whenever any account is created, access to all its files
is restricted to AC (account users only), except for the SYS account,
for which Read and Execute access is allowed for ANY; and Write,
Append, and Lock access for AC; whenever any group is created, access
to all its files is restricted to GU (group users only), except if the
group is PUB, in which case access is Read and Execute for AC (all
account users) and Write, Append, and Lock for GU (group users) and AL
(account librarian); and whenever any file is created, access to it is
allowed to everyone. Incidentally, a System Manager can access (in any
mode) any file in the system, and an Account Manager can access any
file in his account.
Thus, let us say that you, who build your files in JOHN.DEV, wish
other users to be able to read your files. To do this, you have to go
to your account manager, get him to allow Read access to the group
JOHN.DEV for ANY, and get him to ask the system manager to allow Read
access to DEV for ANY. This, needless to say, is rather complicated,
and, in fact, most users go the much easier route of just :RELEASEing
their files.
However, the problem with :RELEASEing a file is that when you do it,
ANYBODY is allowed to do ANYTHING to the file -- this means read it,
write to it, even purge it! And, since doing this is so easy, many
files are :RELEASEd and never re-:SECUREd, thus leaving them open for
easy tampering by anyone; another contributing factor to this is that
ordinary MPE :LISTF does not show whether or not the file has been
:RELEASEd, so many people don't even know which of their files are
:RELEASEd.
However, if getting the access restrictions on your group and account
loosened is so difficult, but :RELEASEing the file makes it wide-open
for any kind of access, what is to be done? Unfortunately, the
solution is by no means easy.
The first step is to set up all your accounts with all forms of access
allowed to ANY; i.e. alter them with a command such as
:ALTACCT accountname;ACCESS=(R,W,A,L,X:ANY)
This still leaves a level of security (group security) that will by
default protect the file (except for PUB groups, which should
therefore be built with Read and Execute access for AC instead of
ANY), while making the security much easier to waive -- one would need
to lift group security only instead of group and account security.
Next, when building each group, consider closely the security that you
would wish to put on it. If, for instance, this group consists mostly
of files that should be readable by anybody, build it with Read access
allowed to ANY. Files can then be protected individually by :ALTSECing
them to a more restrictive security level.
Finally, if you :RELEASE a file so that someone can access it, be sure
to :SECURE it immediately after the other person is done (unless you
don't care about security for that file). It's even better if you have
some global file manipulation utility (such as VESOFT's MPEX) with
which you can :SECURE all the files in some fileset that have been
:RELEASEd.
Thus, some important file security guidelines exist:
* REMEMBER THAT :RELEASEing A FILE LEAVES IT WIDE OPEN FOR ANY KIND
OF ACCESS; :RELEASE FILES CAUTIOUSLY, AND RE-:SECURE THEM AS SOON
AS POSSIBLE.
* TRY TO MAKE IT AS EASY AS POSSIBLE FOR PEOPLE TO MAKE THEIR FILES
ACCESSIBLE BY OTHERS WITHOUT HAVING TO :RELEASE THEM. THUS, BUILD
ALL ACCOUNTS WITH (R,W,X,A,L:ANY) SO THAT ALLOWING ACCESS TO A
GROUP WILL BE EASIER.
* IF A GROUP IS COMPOSED MOSTLY OF FILES THAT SHOULD BE ACCESSIBLE
BY ALL USERS IN THE SYSTEM OR BY ALL ACCOUNT USERS, BUILD IT THAT
WAY. THIS WILL ALSO REDUCE :RELEASE'S.
* THE :ALTSEC COMMAND IS USEFUL FOR RESTRICTING ACCESS TO FILES IN A
GROUP TO WHICH ACCESS IS NORMALLY LESS RESTRICTED.
One more aspect of file security that bears mentioning is the file
lockword. With it, you could conceivably restrict file access to only
those users (or programs!) who know the file lockword, even if the
file's security matrix says that they have complete access to the
file. However, the problem with lockwords is the same as the problem
with passwords -- they don't stay secret for long. In my opinion,
other security approaches (better use of the security matrices, user
id checks in programs being protected, etc.) are superior.
* LOCKWORDS AREN'T ALL THEY'RE CRACKED UP TO BE. OTHER APPROACHES
SHOULD BE PREFERRED.
ASIDE -- ALLOWING PROGRAMS TO READ :SECUREd FILES
Say that you want your accounts payable program to ask the user for a
password and then check the user's input against a password stored in
a file. Now, you naturally can't store the password in a :RELEASEd
file, for then the password would be readable by anybody; however, if
it is stored in a :SECUREd file, then the program won't be able to
access it either, since the program is run by ordinary users.
One solution is to :RELEASE a file, but put a lockword on it. Then,
the program could open the file specifying the lockword, but users
would not be able to open the file because they wouldn't know the
lockword. This is a relatively good solution; however, its flaw is
that, like all passwords, the lockword is likely to become known
sooner or later. Then, the entire advantage of storing the password in
a file, -- namely that the password can be easily changed -- would be
nullified by the fact that the file's lockword cannot easily be
changed.
A different approach uses an undocumented feature of the FOPEN
intrinsic. If FOPEN is called in privileged mode, and the 4 low-order
bits of the "aoptions" parameter (third from the left) are set to 15,
the file is opened for read access IGNORING ALL SECURITY. This is not
a security violation because it requires PM capability (see the
CAPABILITIES section); however, since PM must be granted to only the
program and the group and account in which it resides (which could be
PUB.SYS), the program will be able to access the file regardless of
who is running it, but most users will not (since the file can thus be
:SECUREd).
CAPABILITIES
There are some MPE capabilities that have a bearing on system
security.
Of these, SM and AM are simple to explain and relatively well
understood -- they allow one to access (in any way) all files in the
system and the account, respectively.
Some others -- AL and GL -- allow one to establish special classes of
users (Librarians) that are allowed to access files because they can
be explicitly allowed access by the security matrices (see FILE
SECURITY).
However, the security effects of two other capabilities -- OP and PM
-- are often not properly appreciated, much to the detriment of system
security.
OP CAPABILITY
OP capability, which stands for System Supervisor (NOT Operator!), has
one property that has a great bearing on system security: a user with
OP capability can :STORE and :RESTORE any file in the system. This
might not mean much, but it really means that
A USER WITH OP CAPABILITY CAN READ AND WRITE ANY FILE IN THE SYSTEM
After all, all he has to do to read it is to :STORE it and then FCOPY
the tape to the line printer; and to write to it, he can store it,
move it to a system on which he has Write access to the file's group
and account, modify it, store it again, and restore it on the original
system. Can you trust your operators (who are usually given this
capability) with this kind of power?
* YOU SHOULD ONLY GIVE OP CAPABILITY TO USERS WHO YOU TRUST AS MUCH
AS YOU WOULD A SYSTEM MANAGER, TO USERS WHO HAVE NO ACCESS TO
MAGNETIC TAPES OR SERIAL DISCS, OR TO USERS WHO HAVE A LOGON UDC
THAT DROPS THEM INTO A MENU WHICH FORBIDS THEM FROM DOING :STORE'S
OR :RESTORE'S
PM CAPABILITY
No capability has been feared, discussed, or maligned quite as much as
PM capability. In this paper, I will discuss only the the security
ramifications of PM capability; for a discussion of PM and system
crashes, see my paper "Privileged Mode: Use and Abuse."
What does PM capability give you? Quite simply, it allows you to
obtain SM capability as follows:
:DEBUG
?MDL-'DL-1'+2
DL-NNN MMMMMM := -1
?E
Once you do this, you are (at least partially) a system manager until
you log off. You can access any file and even execute system manager
commands like :ALTACCT and :ALTGROUP to give yourself SM or any other
capability permanently.
Obviously, PM capability is not something you want to give to every
Tom, Dick, and Harry.
* YOU SHOULD ONLY GIVE PM CAPABILITY TO USERS WHO YOU TRUST AS MUCH
AS YOU WOULD A SYSTEM MANAGER.
However, there are other ways in which users can get PM capability.
For one, for a program to have PM capability (and thus use various
privileged operating system functions), the program must reside in a
group and account which have PM capability. This is very good -- this
way, programs like DBUTIL and SPOOK, which use privileged mode, can be
run by plain vanilla users who do not have to be given PM. However,
this means that if a privileged program does something to circumvent
normal MPE security (see the ASIDE -- ALLOWING PROGRAMS TO READ
:SECUREd FILES), it'll do it for anybody who runs it, unless it
explicitly checks who is running it.
More importantly, this means that a user does not need to have PM
capability to write privileged programs -- only the ability to build
files in a privileged group (i.e. S [Save] access to that group) or to
overwrite a program file in that group with his own file (i.e. W
[Write] access to any program file in that group) and then run them
(i.e. X access to the program file being overwritten or any access if
he has S access to the group -- then he can just release the file).
For instance, say that I work out of EUGENE.DEV and the group PROG.DEV
has PM capability and Save access for all account users. I can just
write a program that uses privileged mode to access a file that I
shouldn't be able to access or to grant myself all the capabilities
(like in the :DEBUG example above), :PREP it without CAP=PM (since
:PREPing with CAP=PM requires PM capability), then change the program
file to have PM capability (a task that does not require privileged
mode), and copy it into PROG.DEV. Although I couldn't run this program
while it was in EUGENE.DEV (since it is required that the group in
which the program resides have PM capability), once it is in PROG.DEV,
I could run it. If I don't have execute access to PROG.DEV, I can
:RELEASE the program before running it, since I am the creator of the
file.
Or, say that somebody :RELEASEd any program file in PUB.SYS, thus
giving me write and execute access to it. Then, I can write a program
that uses privileged mode to bypass system security, :PREP it without
CAP=PM, change the program file to have PM capability, and copy it on
top of that program file in PUB.SYS. Then, since PUB.SYS has PM
capability and I have execute access to the file I just overwrote, I
can run the program.
Thus,
* IF ANY USER HAS SAVE ACCESS TO A GROUP WITH PM CAPABILITY, OR
WRITE AND EXECUTE ACCESS TO ANY PROGRAM FILE THAT RESIDES IN A
GROUP WITH PM CAPABILITY, HE CAN WRITE AND RUN PRIVILEGED CODE.
And, since :RELEASEing a file gives everyone write and execute access
to it,
* *NEVER* :RELEASE A PROGRAM FILE THAT RESIDES IN A GROUP WHICH HAS
PM CAPABILITY!
As if this wasn't enough, there are some other potential security
violations that can occur with privileged mode. Consider the following
circumstance:
Two HP3000s, which we will call O-machine (intended for OPEN access)
and S-machine (which the system management wants SECURED) are linked
via DS/3000. A person has a user id and a group with PM capability on
O-machine and a plain vanilla user id and group with only default
capabilities on S-machine. S-machine management thinks that its
machine is secure, since only MANAGER.SYS and PUB.SYS have PM
capability on their machine.
Now, there are several file system operations that bypass system
security and thus require privileged mode; for instance:
* FOPEN with the 4 low-order bits of aoptions set to 15 (see ASIDE
-- ALLOWING PROGRAMS TO READ :SECUREd FILES), when called from
within privileged mode, lets you read a file even when you have no
access to it.
* FOPEN with EXECUTE access (4 low-order bits of aoptions set to 6;
document in System Intrinsics manual), when called from within
privileged mode, lets you read and write a file if you have only
execute access to it.
* MUSTOPEN, a procedure identical to FOPEN in all respects except
that, when called in privileged mode, it ignores a file's
lockword.
* FOPEN of a privileged file (a file with a negative filecode, such
as an IMAGE database).
These are not inherently security violations: in fact, as the ASIDE --
ALLOWING PROGRAMS TO READ :SECUREd FILES section shows, they can be
used to actually INCREASE your security. However, they are not
security violations only because they require PM capability to be
executed.
Now, consider our would-be security violator. He has his eyes on the
S-system file FOO.JOB.SYS, which he knows is a job stream that
contains an embedded password (it could just as well contain any other
kind of sensitive data). He signs on to O-system as a privileged user,
and then to the S-system via DS as a plain vanilla user. Now, because
DS allows a program on one system to open a file on another system (by
specifying the file's device to be the dsline device followed by a
"#", e.g. "60#"), our user writes a program on O-system that opens
file FOO.JOB.SYS in the "ignore security" mode (aoptions 4 low-order
bits = 15) on S-system. Since the program is running in privileged
mode (remember, our O-system user is privileged), the open succeeds,
and the user can read the file!
Now note that the file system does not check that the user on S-system
must have PM capability to use this security-bypassing mode; the
program need merely be running in PM capability, regardless of which
system it is on!
This is one of the few genuine flaws in MPE's security system, and
it's nothing to sneeze at. What it means is that
* IF TWO HP3000'S ARE CONNECTED VIA DS, AND A USER HAS PM CAPABILITY
ON ONE AND AN ORDINARY LOGON ON THE OTHER, HE CAN VIOLATE THE
OTHER'S SECURITY. THUS, IF ANY HP3000 IN A DS NETWORK IS BROKEN
INTO OR LEFT OPEN, ALL OTHERS ARE IN GRAVE DANGER.
Thus, if you want to keep one system secure, you must keep all systems
hooked up to it via DS secure as well.
One other issue, somewhat more arcane but nonetheless relevant, arises
when using privileged mode. If a program which has PM capability calls
DEBUG when the user running it does not have PM capability, even
though the user will be dropped into non-privileged DEBUG, he can use
this to break system security.
Briefly, the user can modify some data in the program's stack or the
program's P pointer (which points to the current instruction being
executed) to cause the program to do something other than what it is
supposed to do when it performs its privileged operations. One thing
that actually happened to one of my programs is that it called the WHO
intrinsic, figured out the logon user, account, and group, put them
into global arrays, and then went into privileged mode and got the
logon user, account, and group passwords and wrote them to a stream
file. This was perfectly kosher -- if a user managed to sign on, he
already knows his logon passwords; however, the program allowed the
user to enter DEBUG even though he was non-privileged. Although the
program did not call DEBUG when privileged, and the user was not put
into privileged debug, the user could modify the user, account, and
group id arrays in the stack to read, say, "MANAGER","SYS", and "PUB".
Then, the next stream the program built would contain MANAGER.SYS's
passwords!
This is, as I said, a rather arcane and relatively infrequent problem;
however, it is a possible security flaw nonetheless, and should not be
ignored. In fact, I'd like to ask HP to correct its DBDRIVER program,
which is privileged and has a which "/D" command which drops the user
into DEBUG whether or not he is privileged.
In the same vein, dynamically loading (via the LOADPROC intrinsic) a
procedure from a user's group or account SL and then calling it should
also be forbidden to privileged programs -- the called procedure, even
though it resides in a non-privileged SL, can call GETPRIVMODE because
the program calling it is privileged. Again, rather arcane but still
worth noting.
Thus,
* PRIVILEGED PROGRAMS MUST NEVER CALL DEBUG UNLESS THEIR USER IS
PRIVILEGED, AND MUST NEVER DYNAMICALLY LOAD AND CALL PROCEDURES
FROM A USER'S GROUP OR ACCOUNT SL UNLESS THE USER IS PRIVILEGED.
Now, I do not intend to unfairly malign PM capability. It has its
uses, and in fact, some programs must have it (such as the HP system
utilities in PUB.SYS or many very useful contributed and
vendor-supported programs). However -- and I cannot stress this enough
-- use of PM must be watched very carefully if you wish to keep your
system secure.
IGNORANCE SECURITY
Many techniques of violating system security described herein may
appear rather complicated and improbable; in fact, they are. It is all
too easy to say: "Well, my users aren't so smart -- they'd never think
of pulling all those tricks." Unfortunately, it is out of such
complacency that insecure systems are born. After all, if we could
think of these tricks, why can't some smart guy in your shop? What if
one of his friends is a sophisticated HP user? The assets of your
company are far too precious a thing to entrust to the presumed
ignorance of your users; you should rather improve the security of
your system, so that even a smart user will not be able to penetrate
it -- and if your users aren't that smart, all the better.
DATABASE SECURITY
IMAGE/3000's security system is probably one of its most complex
features and also one of its least used. My first impulse was to
chastise the HP user community for not using this wonderful security
feature more, and to blame 99.44% of all security violations on their
failure to do so, but then I realized that this is not such a
wonderful facility after all.
IMAGE/3000 security permits the database creator to restrict access to
each individual data item and data set to only those users who specify
a certain password when opening the database. Admittedly, this is a
very useful feature when you expect the database to be accessed via
QUERY -- then you can define exactly what a user can do by what
password you give him. However, most databases are accessed by
application programs, not through QUERY, and most of the time it is
the program, not the user, that specifies the password. So, unless you
intend to reveal certain database passwords to only certain
programmers and thus protect your database against your programmers,
not your users, you are probably far better off implementing
application security, i.e. having your application figure out what a
certain user is authorized or not authorized to do, rather than using
IMAGE security.
* IMAGE/3000 DATABASE SECURITY IS NOT PARTICULARLY USEFUL EXCEPT FOR
PROTECTING DATABASES AGAINST UNAUTHORIZED QUERY ACCESS. IN FACT,
SOME DEGREE OF PROTECTION AGAINST UNAUTHORIZED QUERY ACCESS CAN BE
GIVEN BY USING DBUTIL'S "SET SUBSYSTEM" COMMAND TO DISALLOW ANY
QUERY ACCESS OR QUERY MODIFICATION OF A DATABASE.
DATA ENCRYPTION
If you want to secure your data against unauthorized reading even if
some users manage to access it, they won't be able to understand it.
This is the principle of encryption -- change the format of your data
so that nobody but the authorized people will be able to understand
it.
Usually, encryption algorithms involve the use of so-called "keys."
Say that I want to encrypt the phrase "NOW IS THE TIME FOR ALL GOOD
MEN TO COME TO THE AID OF THEIR COUNTRY." I could do this by choosing
some number (say, 7) and adding it to each letter of the sentence, so
that A would become H, B would become I, C would become J, R (#18)
would become Z, S would become A, etc. Then, the phrase would become
"UVD PZ AOL APTL MVY HSS NVVK TLU AV JVTL AV AOL HPK VM AOLPY
JBVUAYF," an unreadable jumble of letters to anyone who doesn't know
that to decrypt it, one must subtract 7 from each character. Thus, 7
is the key and the encryption algorithm is to add the key to each
character.
Unfortunately, things are a bit more complicated than that, primarily
because with some work, one can realize that the letters A and V occur
quite often, the combination AO occurs frequently as well, and that
there are only so many possible two-letter words (some of which must
correspond to PZ, AV, and VM). Thus, we could find out what key
letters correspond to, and thus decode the entire sentence.
Fortunately, there are more sophisticated encryption algorithms that
are far harder to decrypt. And, since the key need not be stored in
the computer, but only in the user's mind or some other safe place,
encrypted data can be decrypted only by an authorized person.
Another less general but nevertheless useful technique for encrypting
passwords is called "one-way encryption." Say that you wish a user to
enter a password into your program when he is first set up, and then
have your program ask him for the password every time he subsequently
logs on. You do not need to actually decrypt the password -- just
encrypt it once at user set-up time, store it in encrypted form, and
then, every time the user tries to log on, ask him for a password,
encrypt his answer, and compare it against the encrypted real
password.
Thus, your encryption algorithm can map the entire password into a
single number (by, say, adding the squares of all the letters, each
multiplied by the cube of its position in the password string), thus
making it impossible to decrypt; and, the encryption algorithm is much
simpler than two-way encryption algorithms that need to have a
corresponding decryption algorithm. Unfortunately, this technique is
limited to applications in which decryption is never necessary, such
as when passwords are stored.
One-way encryption is easy to do; good two-way encryption is harder --
I know of no HP programs that do it, but hopefully that will be
remedied soon.
* IN GENERAL, ENCRYPTION IS ANOTHER GOOD WAY OF PROTECTING SENSITIVE
DATA FROM UNAUTHORIZED READING.
CONCLUSION
It is all too easy to get involved in the implementation and
perfection of an application system, putting "little things" like
security on the back burner; unfortunately, this is precisely what
accounts for the alarming amount of computer crime that is threatening
us today. What is best is that with application of some simple
guidelines and a little time and effort, you could dramatically
decrease your chances of becoming a victim. No security system will
cut these chances to zero, but if you have as much valuable data in
your machine as the average HP user has in his, doing nothing can
literally cost you millions.
* THE USER IS THE WEAKEST LINK IN THE LOGON SECURITY SYSTEM --
DISCOURAGE HIM FROM REVEALING PASSWORDS (by techniques such as
personal profile security or even by reprimanding people who
reveal passwords -- they seem innocent, but they can lose you
millions).
* PASSWORDS EMBEDDED IN JOB STREAMS ARE EASY TO SEE AND VIRTUALLY
IMPOSSIBLE TO CHANGE -- AVOID THEM.
* SOME FORMS OF ACCESS ARE INHERENTLY SUSPECT (AND THUS REQUIRE
EXTRA PASSWORDS) OR ARE INHERENTLY SECURITY VIOLATIONS. THUS,
ACCESS TO CERTAIN USER ID'S AT CERTAIN TIMES OF DAY, ON CERTAIN
DAYS OF THE WEEK, AND/OR FROM CERTAIN TERMINALS (SUCH AS DIAL-IN
OR DS LINES) SHOULD BE SPECIALLY RESTRICTED.
* MANY SECURITY VIOLATIONS CAN BE AVERTED BY MONITORING THE WARNINGS
OF UNSUCCESSFUL VIOLATION ATTEMPTS THAT OFTEN PRECEDE A SUCCESSFUL
ATTEMPT. IF POSSIBLE, CHANGE THE USUAL MPE CONSOLE MESSAGES SO
THEY WILL BE MORE VISIBLE.
* LEAVING A TERMINAL LOGGED ON AND UNATTENDED IS JUST AS MUCH A
SECURITY VIOLATION AS REVEALING THE LOGON PASSWORD. USE SOME KIND
OF TIMEOUT FACILITY TO ENSURE THAT TERMINALS DON'T REMAIN INACTIVE
FOR LONG; SET UP ALL YOUR DIAL-IN TERMINALS WITH SUBTYPE 1.
* A USEFUL APPROACH TO SECURING YOUR SYSTEM IS TO SET UP A LOGON
MENU WHICH ALLOWS THE USER TO CHOOSE ONE OF SEVERAL OPTIONS RATHER
THAN TO LET THE USER ACCESS MPE AND ALL ITS POWER DIRECTLY.
* BLOCKING OUT MPE COMMANDS VIA UDC'S WITH THE SAME NAME WILL
USUALLY FAIL UNLESS THE COMMAND IS :SETCATALOG OR :SHOWCATALOG OR
IF YOU ALSO FORBID ACCESS TO MANY HP SUBSYSTEMS AND HP-SUPPLIED
PROGRAMS. THIS SEVERELY LIMITS THE USEFULNESS OF THIS METHOD.
* REMEMBER THAT :RELEASEing A FILE LEAVES IT WIDE OPEN FOR ANY KIND
OF ACCESS; :RELEASE FILES CAUTIOUSLY, AND RE-:SECURE THEM AS SOON
AS POSSIBLE.
* TRY TO MAKE IT AS EASY AS POSSIBLE FOR PEOPLE TO ALLOW THEIR FILES
TO BE ACCESSED BY OTHERS WITHOUT HAVING TO :RELEASE THEM. THUS,
BUILD ALL ACCOUNTS WITH (R,W,X,A,L:ANY) SO THAT ALLOWING ACCESS TO
A GROUP WILL BE EASIER.
* IF A GROUP IS COMPOSED MOSTLY OF FILES THAT SHOULD BE ACCESSIBLE
BY ALL USERS IN THE SYSTEM OR BY ALL ACCOUNT USERS, BUILD IT THAT
WAY. THIS WILL ALSO REDUCE :RELEASE'S.
* THE :ALTSEC COMMAND IS USEFUL FOR RESTRICTING ACCESS TO FILES IN A
GROUP TO WHICH ACCESS IS NORMALLY LESS RESTRICTED.
* LOCKWORDS AREN'T ALL THEY'RE CRACKED UP TO BE. OTHER APPROACHES
SHOULD BE PREFERRED.
* YOU SHOULD ONLY GIVE OP CAPABILITY TO USERS WHO YOU TRUST AS MUCH
AS YOU WOULD A SYSTEM MANAGER, TO USERS WHO HAVE NO ACCESS TO
MAGNETIC TAPES OR SERIAL DISCS, OR TO USERS WHO HAVE A LOGON UDC
THAT DROPS THEM INTO A MENU WHICH FORBIDS THEM FROM DOING :STORE'S
OR :RESTORE'S
* YOU SHOULD GIVE PM CAPABILITY ONLY TO USERS WHO YOU TRUST AS MUCH
AS YOU WOULD A SYSTEM MANAGER.
* IF ANY USER HAS SAVE ACCESS TO A GROUP WITH PM CAPABILITY, OR
WRITE AND EXECUTE ACCESS TO ANY PROGRAM FILE THAT RESIDES IN A
GROUP WITH PM CAPABILITY, HE CAN WRITE AND RUN PRIVILEGED CODE.
* *NEVER* :RELEASE A PROGRAM FILE THAT RESIDES IN A GROUP WHICH HAS
PM CAPABILITY!
* IF TWO HP3000'S ARE CONNECTED VIA DS, AND A USER HAS PM CAPABILITY
ON ONE AND AN ORDINARY LOGON ON THE OTHER, HE CAN VIOLATE THE
OTHER'S SECURITY. THUS, IF ANY HP3000 IN A DS NETWORK IS BROKEN
INTO OR LEFT OPEN, ALL OTHERS ARE IN GRAVE DANGER.
* PRIVILEGED PROGRAMS MUST NEVER CALL DEBUG UNLESS THEIR USER IS
PRIVILEGED, AND MUST NEVER DYNAMICALLY LOAD AND CALL PROCEDURES
FROM A USER'S GROUP OR ACCOUNT SL UNLESS THE USER IS PRIVILEGED.
* IMAGE/3000 DATABASE SECURITY IS NOT PARTICULARLY USEFUL EXCEPT FOR
PROTECTING DATABASES AGAINST UNAUTHORIZED QUERY ACCESS. IN FACT,
SOME DEGREE OF PROTECTION AGAINST UNAUTHORIZED QUERY ACCESS CAN BE
GIVEN BY USING DBUTIL'S "SET SUBSYSTEM" COMMAND TO DISALLOW ANY
QUERY ACCESS OR QUERY MODIFICATION OF A DATABASE.
* IN GENERAL, ENCRYPTION IS ANOTHER GOOD WAY OF PROTECTING SENSITIVE
DATA FROM UNAUTHORIZED READING.