Hacking Techniques, by Logan-5 (Hacker Supreme)

****************************
*** HACKING TECHNIQUES ***
*** Typed By: LOGAN-5 ***
*** (Hacker Supreme) ***
*** From the ***
*** Inner Circle Book ***
****************************

1) CALLBACK UNITS:

Callback units are a good security device, But with most phone systems,
it is quite possible for the hacker to use the following steps to get
around a callback unit that uses the same phone line for both incomming
and out going calls:First, he calls he callback unit and enters any
authorized ID code (this is not hard to get,as you’ll see in a moment).
After he enters this ID, the hacker holds the phone line open – he does
not hang up. When the callback unit picks up the phone to call the user back,
the hacker is there, waiting to meet it.

The ID code as I said, is simple for a hacker to obtain, because these
codes are not meant to be security precautions.The callback unit itself
provides security by keeping incomming calls from reaching the computer.
The ID codes are no more private than most telephone numbers. Some callback
units refer to the codes as “location identification numbers,” and some
locations are used by several different people,so their IDs are fairly
well known.I’ve been told that, in some cases,callback ubits also have
certain simple codes that are always defined by default. Once the hacker
has entered an ID code and the callback unit has picked up the phone to
re-call him,the hacker may or may not decide to provide a dial tone to
allow the unit to “think” it is calling the correct number. In any event,
the hacker will then turn on his computer, connect with the system – and
away he goes.If the however, the hacker has trouble holding the line with
method,he has an option: the intercept.

The Intercept:
Holding the line will only work with callback units that use the same
phone lines to call in and to call out.Some callback units use different
incoming and outgoing lines, numbers 555-3820 through 555-3830 are dedicated
to users’ incoming calls, and lines 555-2020 through 555-2030 are dedicated
to the computers outgoing calls.The only thing a hacker needs in order to
get through to these systems is a computer and a little time – he doesn’t
even need an ID code. First,the hacker calls any one of the outgoing phone
lines, which, of course, will not answer.Sooner or later, though, while the
hacker has his computer waiting there, listening to the ring, an authorized
user will call one of the incomming lines and request to be called back.
It will usually be less than an hours wait, but the hacker’s computer
is perfectly capable of waiting for days, if need be.

The callback unit will take the code of the authorized user, hang up,
verify the code, and pick up the phone line to call back.If the unit
tries to call out on the line the hacker has dialed, the hacker has his
computer play a tone that sounds just like a dial tone.The computer will
then dial the number given that matches up with the user’s authorized ID.
After that,the hacker can just connect his computer as he would in any
other case.If he is really serious,he will even decode the touch tones
that the mainframe dialed,figure out the phone number of the user the
system was calling, call the person, and make a few strange noises that
sound as though the computer called back but didnt work for some reason.

2) TRAPDOORS AS A POSSIBLILITY

I haven’t heard of this happening, but i think it is possible that a
callback modem could have a trapdoor built into it.Callback modems are
run by software, which is written by programmers.An unscrupulous programmer
could find it very easy to slip in an unpublicized routine, such as,
“if code =*43*, then show all valid codes and phone numbers.” And such a
routine, of course, would leave security wide open to anyone who found the
trapdoor.The obvious protection here, assuming the situation ever arises,
is simply an ethical manufactorer that checks its software thoroughly before
releasing it.

A trapdoor is a set of special instructions embedded in the large
program that is the operating system of a computer.A permanent,
hopefully secret “doorway”, these special instructions enabe anyone who
knows about them to bypass normal security procedures and to gain access to
the computer’s files.Although they may sound sinister, trapdoors were not
invented by hackers, although existing ones are certainly used by hackers
who find out about them.

3) THE DECOY

One of the more sophisticated hacking tools is known as the decoy, and it
comes in three versions.The first version requires that the hacker have an
account on the system in question. As in my case,the hacker has a
low-security account,and he tries this method to get higher-security
account.He will first use his low-security account to write a program that
will emulate the log-on procedures of the systems in questions.
This program will do the following:

*- Clear the terminal screen and place text on it that makes everything
look as if the system is in charge.

*- Prompt for, and allow the user to enter, both an account name and a password.
*- Save that information in a place the hacker can access.

*- Tell the use the account/password entries are not acceptable.

*- turn control of the terminal back over to the system.

The user will now assume that the account name or password was mistyped
and will try again…this time (scince the real operating system is in
control) with more success.You can see a diagram of the way these steps are
accomplished

___________________
| Clear Terminal |
| screen |
|____________________|
||
_________||_________
| Print Compuserve |
| Computer |
|_____ Network ______|
||
_________||_________
| Print “ENTER |
| PASSWORD” |______
|____________________| |
|| |
_________||_________ |
| PASSWORD ENTERED? |__NO__|
|____________________|
||_YES
_________||_________
| SAVE PASSWORD |
| INFORMATION |
|____________________|
||
_________||_________
| PRINT “LOGIN |
| INCORRECT |
|____________________|
||
_________||_________
| LOG OFF/RETURN |
| CONTROL TO |
| OPERATING SYSTEM |
|____________________|

4) CALL FORWARDING

Many people use call forwarding by special arrangement with the phone
company.When a customer requests call forwarding, the phone company uses
its computer to forward all the customers incomeing calls to another
number. Lets say, for example, that you want calls that come to your office
phone to be forwarded to your home phone: A call from you to the phone
company,some special settings in the phone companys computer, and all
calls to your office will ring at your home instead.This little bit of help
from the phone company is another tool used by hackers. Lets say you thought
that the computer you were hacking into was being watched-because the
sysop might have seen you and called the fed’s and your sort of bugged by
this nagging feeling that they will trace the next hacker that calls,
just call the phone company and ask for call forwarding, pick a number,
(ANY NUMBER) out of the phone book and have your calls forwarded to that
number,Hea,Hea, the number you picked is the one that will be traced to,
not yours, so you could be hacking away,they think that they have traced you,
but actually the number you had your calls forwarded too. they enter chat mode
and say (YOUR BUSTED!!!!, WE’VE TRACED YOUR PHONE NUMER THE FEDS ARE ON THE
WAY!!), You could reply (Hea, SURE YA DID! I’D LIKE TO SEE YA TRY AND GET ME!
GO AHEAD!) ,that wont seem very important to them at the time, but it will
sure piss them off when they bust the wrong guy!

5) RAPID FIRE

Memory-location manipulation can be helpful, but there is another, more
powerful,possibility, in some cases: the Rapid-fire method.To understand how
this methos works, you have to know something about the way operationg
systems work.When a user enters a command, the operating system first places
the command in a holding area, a buffer, where it will sit for a few
millionths of a second.The system looks at the command and say’s “Does this
person really have authorization to do this, or not?” Then, the command
sits there a few thousandths of a second while the system runs off to
check the user’s authorization.When the system comes back to the command,
it will have one of two possible answers: “OK, GO AHEAD,” or “SORRY,
GET PERMISSION FIRST.”

Once you are on a system that handles things this way, you can use the
rapid-fire method to change the command while its sitting in the buffer,
waiting to be executed. If you can do this,you can do anything.You can enter
a command that you know will be approved, such as “tell me the time.” As soon
as the system runs off to verify your right to know the time,you change
the command in the buffer to something you know would not be approved-perhaps
“give me a list of all the passwords.” When the system comes back with an
“OK, go ahead,” it responds to your second command, not the first. Of course,
this exchange has to be done very rapidly,but most systems existing today
can be fooled by this trick. The question is,how easy is it to do, and how
much authority do you need? I know of one system that let this one slip.

These are certainly not all the hacker’s little secret tricks and tool’s,
You will probably figure out some better, more efficiant,hacking techniques.

GOOD LUCK!!!!!!
L O G A N – 5
<------------------------------------------------>

ÿ

Introduction to the Primos Operating System by Violence (1989) of The VOID Hackers

_______________________________________________________________________________

INTRODUCTION TO THE PRIMOS OPERATING SYSTEM
Part V (Languages and Advanced PRIMOS Material)

Written by Violence
Copyright (C) 1989 The VOID Hackers
_______________________________________________________________________________

Welcome to the fifth and final part of my series on the PRIMOS operating sys-
tem. In this last installment, I will cover many of the aspects of PRIMOS that
I have overlooked, including:

o Program Types and Execution (Languages)
o All about Access Control Lists (Setting and Editing)
o Abbreviation files (use and investigation thereof)
o The physical system console of a Prime computer system
o The ACL’s and Read/Write Locks Used to Protect the SAD
o Hacking older (outdated) revisions of PRIMOS
o Some useful CPL utilities that enhance PRIMOS
o References and Acknowledgements
o Epilog – The End of a Series

As you can see, part V is the “throw-together, finish-it-up” installment. Here
I will cover everything that I have failed to do so in the previous parts. You
should by now have a fairly good working knowledge of PRIMOS. I hope this last
installment will make all you eager PRIMOS hackers happy. Enjoy!

_______________________________________________________________________________

PROGRAM TYPES AND EXECUTION

From the file extension listing in Part I you can see that There are many diff-
erent types of programs, each with their own file extension. How can you look
at and execute these programs? Well, that’s what this section is all about.

To start off, let’s talk about CPL programs. CPL is Prime’s “Command Procedure
Language” and, like VAX/VMS’s DCL, is an interpreted language for performing
rudimentary tasks. This is not to say that it is unable to perform complicated
tasks, for it most certainly can. Most commonly a user’s LOGIN file will be a
CPL program (usually called CPL’s).

CPL programs are SAM type files and can be SLISTed as usual. There are several
methods for executing a CPL program. In these examples, I will assume the file
is called VOID.CPL. Here are the examples:

OK, cpl void
OK, r void.cpl

The first example illustrates use of the CPL command. When CPL’ing a program,
you need not include the “.CPL” file extension, but you can if you want to. In
the second example we see the R command. R is not really the command name, but
the command’s abbreviation. The full command name is RESUME. RESUME requires
that you include the file extension along with the filename. Should a CPL pro-
gram be located in the CMDNC0 directory, then you can execute it by simply ent-
ering it’s name. An example would be:

OK, void

That would execute the VOID.CPL program located in CMDNC0. In fact, any file
located in CMDNC0 can be executed by simply typing it’s name. You can, of cou-
rse, append the file extension, but that is not necessary.

CPL is a rather rich language and you can write many utilities with it. Every-
thing from a utility to perform mediocre tasks to a full-fledged BBS/Chat prog-
ram. CPL is really beyond a simple scripting langage. One thing Prime should
consider is adding some new commands to CPL and writing a compiler subsystem
for it. Tough work, yes, but the benefits would easily outweigh the problems
involved (at least from my viewpoint). Until then, interpreted CPL is quite OK
though. It’s fast enough.

It is beyond the scope of this series to provide instructions on programming in
CPL, but there are alreasy some files floating around regarding it. The file
in TCSB #1 (by Necrovore) lists all the CPL commands but is not very helpful in
the examples department. With enough reader-response I might sit down and
pound out a good CPL tutorial.

On with the show…

BAS files cannot be executed, as they are BASIC source code. You will want to
compile the source and then execute the compiled code. To enter the BASIC sub-
system you enter BASIC at the command line. Like this:

OK, basic

If the Prime you are on has BASIC/VM (called BASICV) available then I suggest
that you use it, as, unlike standard BASIC, BASIC/VM is virtual in nature,
making the machine’s memory appear to be a hell of a lot larger than it really
is. To invoke BASIC/VM, you would type (at the command line):

OK, basicv

Either way, you should get the “>” prompt. At this point, you need to load in
the BAS file and compile it. All of the following examples assume that you are
using BASIC/VM, as it is a lot more recent in nature. BASIC commands are very
similar to BASIC/VM commands. On with the show. In the following examples I
will show you what it would look like if you were to invoke BASIC/VM, load in
a BAS program called VOID.BAS, compile it, and quit.

OK, basicv
[BASICV Rev. 22.0.0 Copyright (c) 1988, Prime Computer, Inc.]
[Serial #serial_number (company_name)]

>n void.bas
>list

10 ! This is a sample BASIC/VM program
15 ! Written by Violence (C) 1989 VOID
20 !
25 PRINT ‘[BASIC/VM EXAMPLE Rev. 22.0]’
30 !
35 ! That revision level is a joke. Heh.
40 !
45 INPUT LINE ‘Enter some text,’ A$
50 PRINT
55 PRINT A$,LIN 1
60 END

>comp void.bin
>q
OK,

The ‘n’ command stands for NEW (either N filename or NEW filename will work).
It is saying to BASIC/VM that the new filename is to be VOID.BAS. BASIC/VM lo-
ads VOID.BAS into the workspace. The LIST command should be obvious. The COMP
command is the abbreviation for COMPILE. It takes the source code, checks it
for errors, and compiles and links it into a binary file. This file can be
executed by using the RESUME command, as illustrated:

OK, R VOID.BIN

BASIC source code, as well as other types of source code (CBL, FTN, F77, etc.)
will not compile if it contains errors. To enter the other available compilers
you must enter the name of the language compilers. Available compilers consist
of the following:

* BASIC Prime BASIC compiler
* BASICV Virtual memory BASIC compiler
* COBOL COBOL compiler
DBASIC Interpreted BASIC with double-precision arithmetic
* F77 Compiles FORTRAN 77 or FORTRAN IV code
* FTN Compiles FORTRAN IV code
* NCOBOL Non-shared (non-virtual) COBOL compiler
* PL1G Compiles PL/1, subset G code
* PMA Assembles Prime Macro Assembler code
RPG Compiles an RPG II program (non-virtual)
SPL Compiles an SPL program
VRPG Compiles an RPG II program (virtual)

Language systems commonly found on Primes are denoted with an asterisk (*).

Generally, to execute compiled source code, use the RESUME (R) command. If the
program is located in CMDNC0, just issue the filename (less the file extension)
to execute it. Use SLIST to view source code. Most always, source code will
have file extension denoting the language type. If a source code file does not
have an extension then SLIST it. Lots of times a source file will tell you
what language it was coded in in its comment header.

I am not going to go into the other languages as many hackers are not familiar
with high level languages such as FORTRAN IV, FORTRAN-77, PL/1 Subset G, etc.
Quite a few are, but not as many as one would think. The information I have
presented on CPL and BASIC/VM is enough to get you on your way, and besides,
there are other means of learning these languages:

(a) Looking at source code files and learning
(b) Purchasing language manuals from Prime Computer, Inc.

(A) is easy to do. Just look for files with the extensions ‘.FTN’, ‘.BAS’,
‘.PLP’, ‘.PL1’, ‘.PMA’ and so forth. Remember, ‘.SAVE’ and ‘.BIN’ are compiled
code and not source.

(B) may not seem like a good or easy option, but it’s not so bad at all! Prime
Computer, Inc. will sell you manuals for these languages for about $20 to $25
a piece. Not so bad when you consider most manuals cost even more. Just call
up Prime Computer, Inc.’s Telemarketing Department and request info or buy them
right then and there. Should they ask why you want manuals, tell them you are
a freelance Prime programmer. They love that one. Here’s the address, etc:

Software Distribution
PRIME COMPUTER, INC.
1 New York Ave.
Framingham, MA 01701

(617) 879-2960
ext 2053, 2054

_______________________________________________________________________________

SETTING AND EDITING ACCESS CONTROL LISTS (ACL’S)

You have already learned how to check the ACL (Access Control List) protecting
a specified UFD and you also know what each of the access rights are and what
they mean. If you have forgotten any of these things then please refer to Part
II of this series. First off I will explain ACL’s and how they are set up.
Then I will go into the actual editing and creating of ACL’s.

ACL’s are stored in Access Catagories (ACAT’s) and can protect not only UFD’s,
but also individual files. An ACL is a list of users and access rights for the
objects they cover. Each entry in an ACL governs who has what rights to a par-
ticular filesystem object. Each entry in an ACL is an ordered pair, as is ill-
ustrated by this structural example:

identifier:rights

The two fields in an entry in an ACL must be separated by a colon (:). ACL’s
may contain up to 32 pairs but may not be longer than 160 characters in length,
including blanks.

An identifier is one of three types, a single user ID (such as SYSTEM), a group
identifier (like .PROJECT_ADMINISTRATORS$), or a special identifier (like $REST
meaning everyone else not specified in the ACL).

Access categories are files that contain an ACL. ACAT’s are used to protect a
set of files in a similar matter. A good example of ACAT usage is the SAD UFD
on a Prime computer (located off of MFD 0). SAD is protected in such a manner
that all of the files therein are protected similarly. Basically, ACAT’s are
useful when protecting files in a UFD differently from one another.

Here is a sample ACL for a UFD called STEVE. I will be using this ACL for all
further examples used in this section.

ACL protecting ““:
STEVE ALL
SYSTEM ALL
LOWERY DALURW
JOHNSON DALURW
$REST: NONE

Notice that the owner of this UFD, STEVE, has ALL rights to his UFD. This is
obvious, of course. Also notice that SYSTEM has ALL rights also. This is pro-
bably due to backup reasons, etc. STEVE has also given the users, LOWERY and
JOHNSON DALURW access to his UFD. Possibly they are in the same department and
are working together on a project of some sort. The $REST identifier is a
wildcard indicating that no other system user has any access to STEVE’s UFD.

Let’s say that LOWERY no longer works on the project with STEVE and JOHNSON.
Therefore LOWERY’s access to STEVE’s UFD needs to be terminated. In addition,
JOHNSON needs P (Protect) access to STEVE’s UFD. Lastly, STEVE wants to add
SIMPSON to his ACL (LOWERY’s replacement, perhaps). To perform these changes,
STEVE must edit his UFD’s ACL. To do this he will have to use the EDIT_ACCESS
command (abbreviated EDAC). Here is what he would type:

OK, edac steve lowery: johnson:pdalurw simpson:dalurw

Sorry for the runover, but ACL related command lines are generally lengthy. It
should be easy for you to track the modifications presented in the above examp-
le. Notice that STEVE did not list himself or SYSTEM. Why? Because he wasn’t
making changes to them. When using EDAC you need only list all ACL changes.
The EDAC command will be useful for editing rights into other people’s ACL-
protected UFD’s (assuming you have access to do such). STEVE’s new ACL looks
like this:

ACL protecting: ““:
STEVE ALL
SYSTEM ALL
JOHNSON PDALURW
SIMPSON DALURW
$REST: NONE

If you happen to create an account on a Prime computer you will want to protect
your UFD with an ACL. To do this you will want to use the SET_ACCESS command
(abbreviated SAC). Let’s go back into time when the system administrator of
STEVE’s system created his account. Also assume that the sys admin didn’t cre-
ate a default ACL for STEVE. Here is what STEVE did to create his original ACL
entry:

OK, sac steve steve:all system:all lowery:dalurw johnson:dalurw
$rest:none

Unlike EDAC, SAC requires you to list all ACL fields. Failure to list a field
will cause the field to have NONE as the access right.

EDAC and SAC will usually prompt you as to whether or not you really want to
make the specified changes, if you want to overwrite an existing ACL file, and
so forth. If you supply a -NO_QUERY argument to the end of the entry then you
will not be prompted at all. Abbreviate -NO_QUERY with -NQ. A good example is
SAC’ing an existing ACL to make wholesale modifications. To avoid the ‘are you
sure’ type prompt, type this (using our previous SAC example):

OK, sac steve steve:all system:all lowery:dalurw johnson:dalurw
$rest:none -nq

Remember, when SAC’ing and EDAC’ing ACL’s include the full pathname of the ACL
file. And remember to include the owner as having ALL rights, as failure to do
so can lock you out of a UFD or other filesystem object.

Other access-related commands are LIST_ACCESS (abbreviated LA, detailed in Part
II of this series), RWLOCK, SET_DELETE, and PROTECT. Use Prime’s online ‘HELP’
for descriptions of these commands.

_______________________________________________________________________________

PRIMOS ABBREVIATION FILES

While most PRIMOS commands are not long enough to be an inconvinience, it can
occasionally be irritating to type a command or command with arguments that you
commonly use. The solution? Abbreviations.

PRIMOS fully supports abbreviations. Abbreviations are exactly what they sound
like; shortened commands that represent full commands. Some good examples that
illustrate this are as follows:

(a) Say you like use the -DETAIL argument of the LD command as opposed
to the normal form of LD. Instead of having to type LD -DET all
the time you can create an abbreviation called LF that will, when
issued, tell PRIMOS to do an LD -DET.

(b) Say you frequently issue the CLOSE ALL command. Wouldn’t it be
nicer to be able to type CA instead of CLOSE ALL all the time?

(c) Say you create many temporary (T$xxxx) files and that you have to
delete these files when done with your session. Instead of ‘hand-
deleting’ them before you logout, make an abbreviation called DT
that PRIMOS interprets as DELETE T$@ -NQ.

Those three examples illustrate the usefulness of abbreviation files. Another
nice fact about abbreviation files is that people occasionally store passwords
to passworded UFD’s (non-ACL) and NUA’s to various and sundry systems on the
network. So inspecting peoples’ abbreviation files is also good hacking pract-
ice. In this section I will describe how to access, list, use, and create abb-
reviation files.

Abbreviation files can be called from within CPL program as well as used during
interactive sessions. Another important fact about abbreviation files is that
they can contain only normal commands and not subcommands. That is to say, you
can abbreviate any normal command line procedure, but you cannot make an abb-
reviation to enter NETLINK, call and NUA, and THEN log you in.

The system administrator can turn abbreviation files on and off, thus some ins-
tallations will not be able to use abbreviation files.

First off lets learn how to look at and use existing abbreviation files (ABBREV
files). At the start of a session you must tell PRIMOS to ‘turn on’ your abb-
reviation file. Usually a user’s LOGIN.CPL or LOGIN.COMI file will do this for
you, but if you want to look inside another user’s ABBREV file you will need to
know how to do this from the PRIMOS command line. Type:

OK, abbrev pathname

where ‘pathname’ is the full pathname of the ABBREV file you wish to activate.
To see what is inside the ABBREV file, issue the following command:

OK, abbrev -list

Very simple. To deactivate an ABBREV file, simply type:

OK, abbrev -off

If you wish to turn the ABBREV file back on, type:

OK, abbrev -on

If you have activated a new ABBREV file (with the ‘ABBREV pathname’ command)
then you will have to use the ‘ABBREV pathname’ file to turn the ABBREV file on
again.

Note that logging off will automatically turn on an active ABBREV file. Also
note that you can only have one active ABBREV file at any given time.

To create a brand new ABBREV file, you need to issue the following command:

OK, abbrev newpathname -create

An example would be:

OK, abbrev void -create
OK,

Sub: Other Nets [BitNet etc..]
Read: (1-30), Message # 30, (c/r)=Next Msg ?::R

30/30: Last prime file 10 of 10…
Name: Predat0r #1 @5211
Date: Sun May 05 22:40:43 1991
From: Youth International Party Line (Kentucky)

Now you have an empty ABBREV file named VOID. Abbreviations consist of two
parts, a name and a value. Names can be up to 8 ASCII characters in length and
can contain any character except for spaces, single-quotes (‘), commas (,),
greater-than symbols (>) and vertical bars (|). Also remember that PRIMOS con-
verts all command line text to UPPER CASE, so case is irrelevant in the name.

NOTE: Do NOT start an abbreviation name with a hyphen (-). If you do then you
will have to enclose the entire name in single-quotes (‘) whenever you
issue the ABBREV command. Example, an abbreviation named -VOID can only be
called if you type ‘-VOID’ and so forth.

Values contain the ASCII text that the abbreviation name represents (ie, the
actual command line procedure). Values can contain all characters.

Now let’s create a sample ABBREV file. Let’s fill it up with some useful abb-
reviations. Type:

OK, abbrev -add test cpl test
OK, abbrev -add ca close all
OK, abbrev -add lf ld -det
OK, abbrev -list
Abbreviation file: TVH>VOID
Abbreviations: 2

TEST cpl test
CA close all
LF ld -det

OK,

Okay, here we have just created three abbreviations. These abbreviations will
now be interpreted as commands by the PRIMOS command line. Thus, typing:

OK, test

will execute the CPL program called TEST (or TEST.CPL; recall that CPL does not
require you to enter the file extension). CA would act just like you had typed
CLOSE ALL, and so on. Be aware that an abbreviation file cannot contain more
than 200 abbreviations.

To delete an abbreviation file entry, type:

OK, abbrev -delete abbrevname

Thus, to delete the TEST abbreviation, we would type:

OK, abbrev -delete test

These are the basics of the abbreviation subsystem. There are more advanced
commands that I have not gone over due to spacial limitations. To obtain more
information on the abbreviation subsystem, type:

OK, abbrev -help

_______________________________________________________________________________

THE PHYSICAL SYSTEM CONSOLE

The physical system console of a Prime computer has added power over any other
local or remote terminal. It is only from this one specific console that
several potent operator commands can be issued and invoked successfully.

A few of these console-specific commands will be boring to any hacker not into
system programming on a Prime. Some commands, however, will be rather useful.
About the most useful console command is the ‘RESUS -ENABLE’ command. As you
might recall from Part III, RESUS is the REmote System USer facility. That is
to say, when RESUS is enabled and you are logged into an administrator account,
you will actually be a virtual system console. This will allow all console
commands to be able to be used from any local or remote terminal. The -ENABLE
argument simply tells PRIMOS that you want to turn RESUS on.

Another useful console command is the user logoff command. With this you will
be able to logoff users other than yourself. This is not advised.

Other useful commands are the log management commands. These will allow you to
make your presence on the system virtually unknown. Simply edit all logs, both
PRIMOS and NETWORK related, and kill all references to yourself. There is much
that you can do. For a full list of operator commands you will have to invoke
the online HELP facility by typing, you guessed it, HELP. Without an argument,
it should list all the PRIMOS commands. Just pick out those that say ‘Operator
Command’ beside them.

I’m not really going to continue with this topic as you will have a hard time
getting console capability unless you are on-site or the fools have RESUS
enabled and you are using a SYS1 priv’ed account. You don’t need the logging
commands to edit the logs (just the SYS1 privs). Lastly, there are ways of
getting console that I will not discuss. I just want you to know that there
are additional methods available and that you should work at finding them. Its
the best way to really learn (besides, it’s too sensitive to release to the
general hacker community).

_______________________________________________________________________________

THE ACL’S AND READ/WRITE LOCKS USED TO PROTECT THE SAD

It should prove both helpful and informative to know how the SAD (System Admin-
istration Directory) is protected. The following ‘map’ displays the SAD ACL’s
and their associated access rights.

SAD – System Administrator Directory
|
| (System Administrator: ALL)
| (Login Server: ALL)
| (Everyone Else: LU)
______________|_______________________________________
| | | | |
UVF SDF MGF MPF PD (Sys Admin: ALL)
(DEFAULT) (DEFAULT) (PA.ACAT) (PA.ACAT) | (Login Srv: LUR)
| (PA.ACAT: LURW)
______________________________________________________|
| | | | |
MPP PVF PPPF PDF BACKUP
(Sys Admin: RW)(DEFAULT) (DEFAULT) (DEFAULT) (Sys Admin: ALL)
(Login Srv: R) (PA.ACAT: DALURW)
(PA.ACCR: R)

PA.ACAT = System_Administrator: RW
.PROJECT_ADMINISTRATORS$: RW

SAD = System Administration Directory UVF = User Validation File
SDF = System MGF = Master Group File
MPF = Master Project File PD =
MPP = Master Project Profile PVF = Project Validation File
PPPF = PDF =
BACKUP = Backup of PA.ACAT PA.ACAT = Project Admin Access Cat

_______________________________________________________________________________

HACKING OLDER (OUTDATED) REVISIONS OF PRIMOS

I hadn’t planned on covering any pre-19.x.x revisions of PRIMOS, but I thought
some of you avid network hackers might be interested to know the very basics
about these insecure revisions.

Revisions 18.x.x, 17.x.x and earlier will actually tell you whether or not a
given user ID is valid before asking you for a password. This makes it a
rather trivial task of determining whether or not a given account exists. In
my experiences early revisions of PRIMOS will be found only on obscure nets,
like those in Brazil and Japan. On these archaic revisions of PRIMOS you can
enter CTRL-C as the password of a valid account and automatically bypass the
front door password security. Very nice. You can barely find these ancient
revisions anymore.

These older revisions are not at all like the current revisions of PRIMOS. I
suggest reading the ‘HACKING PRIMOS’ article by Nanuk of the North if you plan
on penetrating these revisions, as his file was written in the days when 18.x.x
was common.

Not really much more that I can say, as you’ll probably never come across these
revisions and even if you do, the command structure they use is enough to cause
severe gastro-intestinal disorders.

_______________________________________________________________________________

SIMPLIFIED MEANS OF ATTACHING TO SUB-UFD’S

Sub-directories are great, but when you start going deeper than 2 levels on a
Prime it starts getting to be a pain. Full pathnames get to be depressing when
you are 6 or 7 levels deep. Enter the UP and DOWN external commands. Recall
that I mentioned these commands in Part II of this series. These externals are
found on most Primes, but there are a few that do not have them available.

******** I did not write these utilities. Many versions exist on different
* NOTE * systems. I have yet to see copyright notieces, so I will assume that
******** they are either examples from the CPL Reference Manual or Pub Domain.

_______________________________________________________________________________

DOWN.CPL SOURCE CODE

/* DOWN.CPL, DOWN_ATTACH, WHO_KNOWS, 02/24/89
/* An external command to simplify down-ATTACHing.
/*
/* START-CODE:
/*
&args path
&do &while [null %path%]
&s path := [response ‘UFD to Down-ATTACH to’ ”]
&end
a *>%path%
type Now attached to %path%
&return
/*
/* END-CODE

_______________________________________________________________________________

UP.CPL SOURCE CODE

/* UP.CPL, UP_ATTACH, WHO_KNOWS, 02/24/89
/* An external command to simplify up-ATTACHing.
/*
/* START-CODE:
/*
&args num:dec=1
&s path := [dir [pathname *]]
&do I := 1 &to %num%
&s path := [dir [pathname %path%]]
&end
a %path%
type Now attached to %path%
&return
/*
/* END-CODE

_______________________________________________________________________________

A PRIMOS IMPLEMENTATION OF THE UNIX “FILE” COMMAND

I really like the UNIX “file” command. Instead of accidentally viewing a comp-
iled program or other non-ASCII file, I check and see if it is a text file by
using the “file” command. PRIMOS, unfortunately, does not have a simple means
for you to obtain such information. You can best get the information from one
of the LD arguments, but that’s a pain in the ass when you just want the stats
one one file and the UFD has lots of files in it. Thus was caused the PRIMOS
implementation of the UNIX “file” command.

The UNIX “file” command simply tells you the filetype of the specified file.
The PRIMOS implementation of “file” tells you:

o Filename
o Filetype
o Size (in bytes)
o Date and time of last modification

Following are the filetypes understandable by the FILE command:

o ACAT for an access category
o DAM for a direct access file
o SAM for a sequential access file (ASCII text)
o SEGDAM for a segmented direct access file
o SEGSAM for a segmented sequential access file
o UFD for a directory (UFD)
o UNKNOWN if file is not of a recognized type

CAVEAT – all error messages when using “file” are suppressed.
no wildcard capability (yet).

_______________________________________________________________________________

FILE.CPL SOURCE CODE

/* FILE.CPL, FILE_INFORMATION, VOID, 02/24/89
/* PRIMOS version of the UNIX System V ‘file’ command.
/* This source code is in the public domain.
/*
/* Version Date Programmer Description
/* 1.0 02/02/89 Violence Initial coding.
/* 2.0 02/24/89 Violence Words converted into bytes.
/*
/* START-CODE:
/*
&args filename
&severity &warning &ignore
&if [null %filename%] &then &goto usage
&s filename := [translate %filename%]
&if [exists %filename%] &then &goto file
type ‘File not found. ‘%filename%’ (FILE)’
&return
/*
/* Display file attributes
/*
&label file
&s ftyp := [attrib %filename% -type -br]
&s size := [attrib %filename% -l -br]
&s datm := [attrib %filename% -dtm -br]
&s size := [calc %size% * 2]
&if %size% = 1 &then &s size := %size%’ byte’
&else size := %size%’ bytes’
type %filename%’: ‘%ftyp%’ (‘%size%’); Last Modified ‘%datm%
&return
/*
/* Display FILE usage
/*
&label usage
type
type ‘Usage: FILE {filename}’
type
&return
/*
/* END-CODE

_______________________________________________________________________________

CONCLUSION

All in all I find the PRIMOS operating system excellent, both in power and in
user friendliness. One can do almost anything from PRIMOS and it’s associated
utilities and language systems. It’s every bit as capable as VAX/VMS or UNIX.

Primes have, on the down side, become a lot more difficult to hack. Prime
Computer, Inc. has become aware of the increasing popularity of PRIMOS with
hackers and have taken the appropriate steps in alerting it’s customers. This
probably has already affected you. Defaults are gone. System passwords are in
effect. Increased system security. This makes hacking Prime computers these
days a damn sight more difficult than it once was. To this you may thank all
those people that abused NETLINK on PRIMENET systems and so forth.

Enjoy a Prime when you get in one. Experiment with the operating system. Most
of all, however, LEARN! One need not be malicious to learn. When experiment-
ing, experiment on *YOUR OWN* filesystems, not those of the owners. As I have
said, it is more difficult to obtain PRIMOS and PRIMENET accounts these days.
Cherish and benefit from them, but do not act like an idiot and end up making
it harder for everyone else.

_______________________________________________________________________________

REFERENCES

FDR3108-190L (PRIMOS Commands Reference Guide)
FDR3104-101B (New User’s Guide to EDITOR and RUNOFF)
FDR3250 (PRIMOS Commands Programmer’s Companion)
FDR3341 (BASIC/VM Programmer’s Companion)

Hacking PRIMOS Volumes I and II (by Codes Master)
Hacking PRIMOS I, II, and III (by Evil Jay)
PRIMOS: Networking Communications (by Magic Hassan)
PRIMOS Part I (by Carrier Culprit, LOD/H Tech Journal #2)
PRIMOS (by Nanuk of the North)

_______________________________________________________________________________

ACKNOWLEDGEMENTS

During the course of the writing of this series many people have lent me their
help and support. I now wish to acknowledge those that aided me in this task.

Thrashing Rage – Thanks for the ideas, proofreading, and help in recovering the
original documents when the work disk got 164 disk errors. You saved
me from two weeks of retyping! Thanks!

The Beekeeper – Thanks for getting the documents to the right people at 2600,
“The Hackers’ Quarterly”. Whether or not it actually gets published or
not is not important. What is important is that you thought it was a
worthy-enough series for possible publication. Thanks!

Mad Hacker – Without all of our hours and hours of discussion this series would
not be what it is now. Thanks!

And to all the hackers that have written about the PRIMOS operating system in
the past goes a hearty thanks. Couldn’t have done it without you guys. Thanks
goes to: Prime Suspect, Magic Hassan, The Codes Master, Necrovore, Nanuk of
the North, and The Force. Thanks guys!

_______________________________________________________________________________

EPILOG – THE END OF A SERIES

Here ends the last part of my PRIMOS series. I hope that you have learned some
about PRIMOS and how it can be extremely useful to the hacker. If you wish to
contact me, you can reach me on the following systems:

2600 BBS #4 – The BeeHIve The Dallas Hack Shack
P-80 Systems International The Lost City of Atlantis

I will do my best to answer all questions fielded to me regarding the PRIMOS
operating system. Thanks for a successful series! — Violence (03/8/89)

May the forces of darkness become confused on the way to your house.

_______________________________________________________________________________

End of Part V of “Introduction to the PRIMOS Operating System”
_______________________________________________________________________________

Introduction to the Primos Operating System by Violence (1989) of The VOID Hackers

_______________________________________________________________________________

INTRODUCTION TO THE PRIMOS OPERATING SYSTEM
Part II (Internal Snooping and Basic Commands)

Written by Violence
Copyright (C) 1989 The VOID Hackers
_______________________________________________________________________________

Welcome to Part II of my series on PRIMOS. In this part I will go over such
things as how to make your stay on a Prime computer last longer, basic PRIMOS
commands to memorize, user-to-user communication, internal PRIMOS security, and
how to explore the vast reaches of a Prime computer.

_______________________________________________________________________________

MAKING YOUR STAY LAST LONGER

Now that you have logged in, there are a few things that you should do immed-
iately to insure a nice long visit. You should make this procedure routine and
do it everytime you login.

Once logged in you will, as illustrated in Part I, see the login herald and
then, assuming the account is not captive (there will be a section on Captive
Accounts later in this part), get the system prompt (generally an “OK,”). You
are now using PRIMOS and the prompt signifies that you are at the PRIMOS comm-
and line. Most Primes use the standard “OK,” prompt, but some do not. For
this series, I shall assume that your Prime uses the “OK,” prompt. Now, type
some nonsensical command. Try arf. Here is what should happen:

OK, arf
Not found. ARF (std$cp)
ER!

Notice that when you enter an invalid command you get a new prompt. On all
standard systems, it is “ER!”. Again, this prompt can be changed and, through
out this series, I shall assume that it is set to “ER!”.

NOTE: std$cp means Standard Command Processor. Sometimes instead of std$cp you
will get a (processcommand) error. They are the same thing, just differ-
ent names for different revision levels.

Now that you are in, you are going to want to perform a few actions to make
sure that you are safe. The first of these actions is to turn off all COMO
files. COMO is the abbreviated form of the COMOUTPUT command. COMOUTPUT turns
on a buffer if you will, much like your terminal program’s copy buffer. From
the time a COMO file is turned on everything you type and everything PRIMOS
says to you will be logged to a SAM (sequential access method) file (a text
file). To turn off a COMO file you will type this at the system prompt:

OK, como -e

The “-E” argument means “END” and will end any COMO processes. If you can’t
see what you are typing then perhaps the initiating COMO command turned off
all terminal output. You can turn it back on by typing:

OK, como -tty

To save time, nest the arguments as such:

OK, como -e -tty

The next thing you should do is make sure that you are the only person using
the account you logged in to (we don’t want any irate users on our hands, now
do we?). Do this by typing:

OK, stat -me

Assuming you are logged in as user PRIME, PRIMOS will output the following:

Line
User No oct( dec) Devices
PRIME 87 125( 85)

The “User” column displays your User ID. The “No” column lists your user
number. The “Line” column indicates the AMLC line you are using (the physical
modem line) in both octal and decimal notation. The “Devices” column displays
the current disk partition that you are attached to. In this case, we are
attached to the disk partition.

If you find that there is more than one of you logged in, then you should
make a hasty exit and logout. There is a correct way to logout and an incorre-
ct way to logout. The correct way to logout is listed below. NEVER hang up on
a Prime. Always logout in the illustrated fashion.

OK, rsterm
OK, lo

The RSTERM command empties your terminal read (input) and write (output)
buffers. This throws away anything in your type-ahead buffer and gets rid of
all output pending. The LO command logs you out of the system. When you
logout you will see a message similar to this:

PRIME (user 87) logged out Sunday, 22 Jan 89 16:23:56.
Time used: 00h 08m connect, 00m 03s CPU, 00m 00s I/O.

Everything listed in this message should be self-explanatory by now, but in
case you are still bewildered. The connect time is how long your session
lasted in hours and minutes. The CPU time indicates how much actual time you
manipulated the central processing unit (CPU); listed in minutes and seconds.
The I/O time indicates how much actual disk I/O (access) you performed; in
minutes and seconds.

Assuming that no one else is using the account you are logged in as take a look
and see who else is on the system. Do this by typing:

OK, stat us

The Prime will display the following to you:
Line
User No oct( dec) Devices
SYSTEM 1 asr
SMITH 5 3( 3)
JOHNSON 70 104( 68)
PRIME 87 125( 85)
TIMER_PROCESS 123 kernel
LOGIN_SERVER 124 LSr (3)
DSMSR 125 DSM
DSMASR 126 DSM
SYSTEM_MANAGER 127 SMSr
LIB 129 phant AL132
LQP 130 phant AL133
PR0 131 phant PR2
BATCH_SERVICE 132 phant
SYSTEM 133 phant
SYSTEM 134 phant
SYSTEM 135 phant
SYSTEM 136 phant

Notice how the STAT US command’s user display procedure is identical to that
of STAT ME. Let me explain these users now. What’s there to explain about
users, you ask? Why, lots. Some of the users listed abover aren’t actual
people, but rather phantom users, processes that execute on their own.

Look at SYSTEM. See how this User ID doesn’t have a line listing? Instead of
the familiar octal and decimal AMLC line listing, it says “asr” instead. Also
notice how TIMER_PROCESS is listed as “kernel”. The list goes on too, as you
can see. LOGIN_SERVER is “LSr”, DSMSR and DSMASR are “DSM”, and SYSTEM_MANAGER
is “SMSr”. Also notice all those users listed as “phant”.

Basically, all User ID’s that lack octal/decimal AMLC line notation are not
actual people and cannot harm you with the exception of SYSTEM_MANAGER and
SYSTEM. These users, while not people, are consoles, terminals if you will,
that are logged in all the time. One monitors the system’s front door and
logs to screen and disk (and occasionally printer) all logins (successful and
unsuccessful) and logouts. The other just sits there, waiting for the system
manager to do what ever he likes. A good way to tell if either of these User
ID’s is active, is to look and see where they are attached to (ie, the info
displayed in the “Devices” column). If you see it attached to an MFD (Main
File Directory) other than the root MFD, then cruise and come back later. I
will explain this a bit more in a second.

LSr is the login server. It is what you “talk to” (in a manner of speaking)
when you connect to the Prime initially. “kernel” is the heart of the PRIMOS
operating system. When you have logged in, you are talking directly to it.
“phant” users are phantom processes (batch jobs) that are executing independant
of a system terminal. They perform rudimentary tasks such as running the prin-
ters, backing up the system, running the RJE and Batch Job managers, etc. They
perform many activities, almost always geared towards the system’s needs. DSM
users are Distributed System Management utilities runnung as phantoms. The DSM
utilities are present to help the System Admin administrate his system. There
will be more on the DSM utilities in Part III of this series.

To help you out, I have prepared these two tables. They cover all of the above
procedures and what you should do. For the first few times, you should use the
tables. When you have memorized them you will be doing pretty good.

LOGIN PROCEDURE

1. COMO -E
2. STAT ME (is there more than 1 of me logged in? Yes? Logout!)
3. STAT US (are there lots of users online? Yes? Logout!)

LOGOUT PROCEDURE

1. RSTERM
2. LO

That should do it for this section. I will now go into the basic PRIMOS comm-
ands that you should familiarize yourself with and memorize.

_______________________________________________________________________________

BASIC PRIMOS COMMANDS AND INFORMATION ABOUT PRIMOS FILES

We’re all ready to start covering the first PRIMOS commands to add to your new
repetoire. In this section you will learn how to move around PRIMOS directory
structures, how to view files, how to get full status on the Prime system, and
how to get further help.

First off, let me tell you a little bit about directories and how they are set
up. On each logical disk on a Prime, there is a root directory called the MFD
(Main File Directory). Each MFD on a system has a unique number after it. In
this manner all logical disk MFD’s are separate from one another. Below the
MFD’s are directories called UFD’s (User File Directories). It is the UFD’s
that users login to. Not all UFD’s, however, are login directories. All dir-
ectories below the UFD level are called sub-UFD’s (subdirectories). An illus-
tration of what I am talking about follows.

MFD 0 ————- MFD 1 ————- MFD 3 ————- MFD 4
______|______ ______|______ ______|______ ______|______
| | | | | | | | | | | |
UFD UFD UFD UFD UFD UFD UFD UFD UFD UFD UFD UFD
| | | | |
SUB SUB SUB SUB SUB
UFD UFD UFD UFD UFD

Notice that not all UFD’s have sub-UFD’s. Not illustrated is the fact that
sub-UFD’s can have sub-UFD’s under them. It’s set up a lot like most micro-
computer Disk Operating Systems.

When you login you will be attached to your account’s initial attach point (ie,
your “home” directory). This will most likely be a UFD, but in some cases you
will attach to an MFD. In any case, to move from directory to directory you’ll
use the ATTACH command. You can abbreviate ATTACH with an A. PRIMOS underst-
ands ATTACH and A as being the same command. The basic format of ATTACH is:

ATTACH pathname

To attach to an MFD you would type:

OK, a mfd #

Where # is the logical device number of the MFD you wish to attach to. MFD nu-
mbers always start out at 0 and increment sequentially. More on this in a few.
If you are attached to an MFD or a UFD you simply need to use the UFD name you
wish to attach to as the pathname. If you wish to attach to sub-UFD’s then you
will need to use the full pathname. Here are some examples:

OK, a mfd 0
OK, a primenet*
OK, a info
Top-level directory not found or inaccessible. INFO (ATTACH)
OK, a primenet*>info

Notice how when you tried to attach to info you got an error. Well, that was
because info is a sub-UFD and you need to supply the full pathname when you at-
tach to sub-UFD’s. Notice that when you attached to info in the correct manner
you used the “>” character to separate the elements of the pathname.

Locating all the available MFD logical device numbers is easy. Just type:

OK, stat disk

PRIMOS returns this output to you:

Disk Ldev Pdev System
COMDEV 0 1460
USER01 1 31460
USER02 2 32462
USER03 3 462
USER04 4 11062
USER05 5 62060
USER06 6 101062

“Disk” indicates the actual disk partition’s root pathname. “Ldev” is the
logical device number of a given partition. “Pdev” is the physical device
number. The “System” column will be blank unless a given disk partition is
located on another system. What? Impossible? Not at all. With PRIMENET,
Prime’s networking software, disk partitions on system B can be accessed from
system A. If you are not on a system equipped with PRIMENET then the “System”
column will be blank. More on this in the PRIMENET section.

What is important to us immediately is the data in the “Disk” and “Ldev” col-
umns. Each of these disk partitions is an MFD

On some systems you will find two useful utilities, UP and DOWN. These are ex-
ternal commands. They simplify moving about directories in PRIMOS. Here is
how to use them.

UP [n]

UP allows you to move up a specified number of levels. The specification of
“n” is optional. If you do not specify a value for it, it will have a default
value of 1.

DOWN directory_name

DOWN allows you to move down one directory in the tree. You must specify the
name of the directory that you wish to move down into. You need only specify
the UFD or sub-UFD name. There is no need to specify the entire pathname.

If these utilities are not on the Prime you are on then you can upload them to
the Prime’s CMDNC0 directory (where external commands are stored). There will
be more information on this in Part V.

Viewing files in PRIMOS is as easy as can be. You simply use the SLIST (seq-
uential List) command. The format is as follows:

SLIST filename

You must include the file extension of the file that you are SLISTing. Briefly
here is a list of file types and what they mean.

Extension SLISTable? Description

.ABBREV N Abbreviation files
.BAS Y BASIC source code
.BIN N BINARY image file
.CBL Y COBOL source code
.CC Y C Compiler source code
.COMI Y COMMAND INPUT data files
.COMO Y COMMAND OUTPUT data files
.CPL Y CPL (Command Procedure Language) programs
.F77 Y FORTRAN-77 source code
.FTN Y FORTRAN IV source code
.GVAR N Global variable files
.PL1 Y PL/1, Subset G source code
.PLP Y PLP source code
.PMA Y Prime Macro Assembler source code
.RUN N Prime-written programs; int cmds (compiled)
.SAVE N Prime- and user-written programs (compiled)

NOTE: The “SLISTable” column indicates that the file type in question is a SAM
file (Sequential Access Method; a text file) and can be viewed normally
by the SLIST (Sequential List; like the TYPE command found on most PC’s)
command. You can SLIST non-SAM files, but they will come out as garbage
and that can be a pain in the ass. If you should SLIST a non-SLISTable
file type then use BREAK or CONTROL-P to abort the listing.

A very important command is the LD command (List Directory). LD will display
the contents of the current attach directory. To use it just type:

OK, ld

The LD command supports wildcarding, too. If you should want to display all
the CPL files in a directory, use LD in this manner:

OK, ld @@.cpl

Notice the “@@” in the above command. It tells LD to do a wildcard search for
all files ending with the extension “.CPL”. Just experiment with this aspect
of LD. It’s really quite simple.

Getting more information about the Prime you are on is easy. Just use the
STATUS (abbreviated STAT) and LIST commands. Here are lists of these commands
and what they do.

Remember the STAT US and STAT ME commands I mentioned in Part I? Well, as you
probably guessed, there are several other options to the STATUS command. Here
are the other options and what they do:

NOTE: Capitalized letters in this table indicate the option’s abbreviation.

OPTION MEANING

ALl Display all info available through STATUS.
DEvice Display physical and logical device numbers of
any assigned mag tape drives.
NEtwork Displays the status of other systems to which
your system is attached by PRIMENET.
PRoject Displays the Project ID of all users logged in.
SEmaphores Displays the value of user semaphores that have
been set on the system. A semaphore is a flag
used for synchronizing processes. It is used
by cooperating user processes to control access
to a single shared resource.
SYstem Shows the system nodename and revision of PRIMOS.
UNits Shows you what file units you have open.

Sub: Other Nets [BitNet etc..]
Read: (1-30), Message # 30, (c/r)=Next Msg ?:R

29/30: Prime file 4 of 10
Name: Predat0r #1 @5211
Date: Wed Apr 17 10:33:51 1991
From: Youth International Party Line (Kentucky)

Remember, I did not mention the USers, ME, or DIsks options here, as they were
fully detailed in part I of this series.

If the STATUS command is issued without any options, information is provided
on the following options in this order: SYSTEM, UNITS, DISK, SEMAPHORE, NETWORK
and ME.

NOTE: There will be some information regarding the STATUS NETWORK command in a
later section entitled “HINTS ON HACKING PRIMENET”.

That pretty well sums up the STATUS command. But is that all? Hell no. There
is also the LIST command. If you thought STATUS had a lot of options then wait
until you check this lovely command out. I will only cover the useful options.

First in the syllabus is the LIST_ACCESS command. This command will show you
what User ID’s have access to the UFD that you are currently attached to.
Assume that you are attached to your initial login UFD. Also assume that your
User ID is STEVE.SYS. Here is an example of what LIST_ACCESS would display:

OK, list_access

ACL protecting ““:
STEVE.SYS ALL
SYSTEM ALL
$REST: NONE

The above command example displays all of the ACL’s (Access Control Lists)
regarding your UFD. Notice that you, STEVE.SYS, have ALL rights to your UFD
(naturally). Also notice that SYSTEM has ALL rights too. Why? Most likely
backup purposes. Also notice that $REST (meaning all other user ID’s) has NO
rights. Now, lets assume you ATTACHed to another user’s UFD. Say, JOHN. Here
is what you might get:

OK, a john
OK, list_access

ACL protecting ““:
JOHN ALL
SYSTEM ALL
SIMSON DALURW
$REST LUR

Quite a different story here. Again JOHN and SYSTEM have ALL rights here. But
wait, SIMSON has DALURW access and $REST (everyone else) has LUR. What do
these cryptic phrases mean? This, I would gather, would be a good time for me
to explain the PRIMOS access codes. So without further ado:

Code Right Applies to Allows user to
—- ——— ————- ——————————–
P Protect Directories Change accesses and attributes
D Delete Directories Delete directory entries
A Add Directories Add directory entries
L List Directories List directory entries
U Use Directories ATTACH to directories
R Read Files Read file contents
W Write Files Change file contents

As illustrated above, the ALL and NONE mnemonics are also PRIMOS access codes.
ALL indicates YES to ALL of the above and, as you can full well guess, NONE
indicated that all access is denied.

Also be aware that file systems (groups of files) can be protected by an access
category. To list the access of an access category type the following command:

LIST_ACCESS [category_filename]

Next is the LIST_GROUP command. It lists all of the ACL groups to which you
belong. These groups may govern access to some files on the system. If you
don’t belong to any groups then PRIMOS will reply with:

No groups. (list_group)

Otherwise PRIMOS will respond in the following format:

Groups are: .HELP .ADMINISTRATORS .ETCETERA

The LIST_GROUP command can be abbreviated to LG.

LIST_PRIORITY_ACCESS (abbreviation LPAC) is used to display your priority
access on any given disk partition. While normally you would use LIST_ACCESS
to examine all access rights and priority ACL’s on file system objects, LPAC
is available since a priority ACL can prevent you from accessing directories
and from using the LIST_ACCESS command. Command format is as follows:

LIST_PRIORITY_ACCESS [pathname] [-brief]

The LIST_QUOTA command (abbreviated LQ) is, in my opinion pseudo-worthless
since file quota information is displayed when the LD (List Directory) comm-
and is issued. The LQ command displays current disk quota and storage info-
rmation for the current (or specified) directory. To issue this command, you
need to have L (list) access to the target directory and U (use) access to all
higher directories. The proper command format is:

LIST_QUOTA [pathname] [-brief]

Executed without pathname, LIST_QUOTA returns information regarding the current
directory you are ATTACHed to.

Quotas are storage space constraints set on a directory. The limits are listed
in disk records. A 0 quota is great (indicates no quota). A quota of 1 is
absolutely lousy. A quota of 1000+ is ok. If a directory has a quota of, say,
1000, then the total number of disk records used in that directory and ALL sub-
UFD’s below that may NOT exceed the quota.

If you have P (protect) access on the current UFD then you can use the
SET_QUOTA command to change the UFD quota constraints. I know I am getting off
the subject at hand, but I’ll just say this anyway! 🙂 The format is:

SET_QUOTA pathname [-Max N]

The abbreviation for SET_QUOTA is SQ. The argument -MAX indicates the max.
number of quotas that the specified pathname can store. N is a decimal number.

Back to the LIST commands. Next up is LIST_ASSIGNED_DEVICES. This command
invokes a utility in CMDNC0 that will display all devices hooked up to your
Prime, such as printers, etc. Disk partitions are not listed by the LIST_
ASSIGNED_DEVICES command. Some assignable devices are listed below:

Device Code Meaning

ASYn Asynchronous Communications
Line (a leading zero is required for single
digit names; for example ASY07 must be used
to specify line 7).
Line numbers are in decimal.
CARDR Serial Card Reader
CRn MPC Parallel Card /reader or Reader/Punch
DISK pdisk Physical Partition (pdisk is a
partition (volume) number)
GS0 – GS3 Vector General graphics display terminal
MG0 – MG3 Megatek graphics display terminal
MTn Magnetic tape unit
PRn Line Printer
PTR Paper Tape Reader
PUNCH Paper Tape Punch
PLOT Printer/Plotter
SYNCn Synchronous Communications Line
(a leading zero is required to specify
single digit lines).

You can use the -USER [option] argument to specify a list of users, by name
or number. Assigned devices whose assigning user is not in this list are not
displayed. The default is all users. The format is either:

LIST_ASSIGNABLE_DEVICES -USER {user name}

or

LIST_ASSIGNABLE_DEVICES -USER {user numbers}

Remember, the -USER argument is optional, and not required. It is just useful
for listing assigned devices that were assigned by a particular user.

LIST_ASYNC is another good one. This command displays all of the systems hard-
wired lines and what they are doing. There are three types of assignments that
a line can have, and these are:

FREE Line is free to be assigned
ASSIGNED Line is assigned to a hardware device (printer/etc)
LOGIN Line is available for login (terminal or remote)

The header for the display is as follows:

Line Line Auto speed Line line User User
number use enabled speed protocol number name

Line number is the physical line’s identification name. Line use indicates
how the line is assigned (free, assigned, login). Line speed indicates the
speed of the physical line. Line protocol indicates the line factor (either
TTY or TTYNOP). TTYNOP means TTY not operational. User number indicates
the user number associated with the AMLC line. User name is the actual name
of any user/phantom using that line. I am not too sure about the Auto speed
enabled column.

LIST_COMM_CONTROLLERS displays information on all the communication controllers
present in a system, excluding the Prime Node Controller. Information is given
for each controller and includes the controller name, its type, its device
address, the number of synchronous lines attached, and the number of asynchro-
nous lines attached.

LIST_CONFIG displays the current system configuration.

LIST_LAN_NODES displays all nodes on a Prime LAN300 system. Be aware that this
external command works only with Prime’s LAN300 system (so far as my experience
goes).

LIST_SYNC displays all synchronous lines on a Prime system.

LIST_PROCESS displays the environment of a specified user process. The user’s
process identity is displayed, together with details of its environment which
include: attach points; abbreviation file; active COMI and COMO files; connect,
CPU and I/O times and limits; the user’s ACL groups; and all active remote
identities.

There are several more LIST_ commands, but they are not too important at the
present moment. I’ll let you learn about them on your own via Prime’s excel-
lent online help facility. To use the PRIMOS online HELP facility, just type
HELP. Or, if you know what you need help with, type HELP commandname. Really
quite simple.

_______________________________________________________________________________

USER-TO-USER COMMUNICATION

It is always useful to know how to send and receive messages when on a computer
system, and PRIMOS is no exception. Whether communicating with other hackers
online, or attempting to social engineer a legitimate user or system operator.
Any user on a Prime may send or receive messages. Messages may be sent from:

o any user terminal to any other user terminal
o any user terminal to the system console
o the system console to all user terminals
o the system console to any specific user terminal
o the system console to any system console on another
node of the network (PRIMENET-equipped systems only)

Sending messages to users on a Prime is very easy. The message command form-
at is as follows:

MESSAGE [username] [-NOW] [-ON nodename]
[-usernumber]

The abbreviation for MESSAGE is M. So instead of typing MESSAGE all the time,
you can type M instead.

Notice [username] and [-usernumber]. When sending messages to a user you need
only specify one or the other. If you were to send a message to user SYSTEM
you would type:

OK, m system

That would enable you to send a message to user SYSTEM. Be aware that the
message you send will be displayed to ALL users logged in under the User ID of
SYSTEM. In the case that there are more than 1 user with the same User ID log-
ged in at the same time, you might want to do use the [-usernumber] argument.
It works like this:

OK, m -2

That would send a message to the user with the user number of 2. The message
you send in this case would ONLY be sent to the user with the user number of 2.
Use either the user name or the user number, but not both, for using both will
cause an error to be displayed by PRIMOS.

If may omit the [username] and [-usernumber] arguments then the message will be
sent to the system console. Be careful about this!

The -NOW argument is optional. If it is specified then the message will be
sent to the user immediately. Otherwise the message will be put into a queue
and sent only when the target user has returned to PRIMOS command level.

The -ON argument need only be specified if you wish to send a message to a user
that is logged in on a remote site. This argument will not be required at all
if the Prime you are on is not equipped with either the PRIMENET or the LAN300
networking software packages (by Prime Computer, Inc., of course). In order to
use this argument you need to know the remote system’s nodename. An example of
sending a message to a remote system user is:

OK, m hacker -on sys.c

This would send a message to User ID “HACKER” on the networked Prime system
called “SYS.C”. Remember, you need to know the correct nodename of the remote
system.

Just like in real-life situations (people-to-people), PRIMOS users may or may
not wish to speak to you. So before sending a message, you should make sure
that the user you wish to communicate with is accepting messages. There are
several ways to obtain this information.

Message -STATus – Lists receive state of ALL users
Message -STATus username – Lists receive state of all users
with the name of “username”
Message -STATus usernumber – Lists receive state of all users
with the number of “usernumber”
Message -STATus ME – Lists the receive state of your
own terminal/process.

NOTE: Capital letters in the above forms of the message status commands ind-
icate the legal PRIMOS abbreviations for the commands.

When first initiating a session in which you feel you might be doing some user-
to-user communication you should issue the “Message -STATus” command. This
will display the message receive state of all users presently online. Here is
an example of the output you might receive:

OK, m -stat

User No State
SYSTEM 1 Accept
PRIME 13 Defer
PRIMOS 24 Accept
HACKER 37 Reject
RAGE 42 Accept

In the above example you notice that there are five processes logged in, one of
them being the physical system console. The “No” column denotes the user’s
user number, while the “State” denotes their message receive state.

Notice how there are three message receive states listed, accept, defer, and
reject. In theory, these states are defined as such:

ACCEPT – Enables reception of all messages
DEFER – Inhibits immediate messages
REJECT – Inhibits all messages

If you are set to accept then all messages sent to you will be displayed on
your terminal immediately. In defer mode messages will not appear until what
you are doing is done (ie, a message will not appear while in the middle of a
currently executing command). In reject mode no messages will be received by
you.

Setting a receive state is useful when you do not wish to be disturbed. It is
especially useful to use receive states when using any of the PRIMOS editors or
utilities.

Sending messages while in reject mode and sending immediate messages while in
defer mode is not permitted as the user you are attempting to communicate with
will not be able to respond.

To set your message receive state, simply type:

Message -state

‘-state’ is either accept, defer, or reject. Quite simple.

You are advised to avoid sending messages to the system console as that could
be potentially hazardous to your stay on a Prime computer system. Pestering
legitimate users is also not desired. Use your common sense.

_______________________________________________________________________________

A DISCOURSE ON INTERNAL SNOOPING TACTICS

Once inside a Prime, your paths are many. Some lead to glory, others to delet-
ion of your account (gulp). To aid you in choosing the correct paths, you must
snoop about your newfound host. By doing this, you can learn many things, some
of which include:

o Who owns the Prime and what they are doing on it
o More accounts on the system
o More accounts on DIFFERENT Prime systems

There is plenty for you to do. I strongly urge that you make the snooping pro-
cedure a routine and that you do it *immediately* upon obtaining an account, as
you never know how long it might last.

Finding out who owns the Prime and what they do on it is always rewarding. The
best systems I have been on were Prime Computer, Inc. development systems, 3rd
party development systems, and Prime’s belonging to certain telephone companies
(which shall, of course, remain unmentioned). Depending upon who owns the host
you may obtain a bit more information that you had expected.

More accounts on the system is what you are really after, however. Many users
are exceedingly lax. A brief inspection of all mail in the queue can sometimes
yield accounts, as can individual programs (source code) and documents. There
will be more on this topic in the section entitled, “Exploring the Vast Reaches
of a Prime”.

As for more accounts on different systems, I am saving that for the article on
Prime networking (Part IV). There will be a host of information regarding the
advanced snooping tactics used in order to snoop about PRIMENET-based systems
and their respective Token-Ring/LAN300 networks.

_______________________________________________________________________________

INTERNAL SECURITY

Before you can really start exploring your new Prime, you need to understand
how PRIMOS internal security is implemented and how to get around it. As you
have seen from the section con basic PRIMOS commands, PRIMOS utilizes access
control lists (ACL’s). Getting around ACL’s is almost an impossibility. There
will be a full discussion on ACL’s in Part V.

Also you will occasionally run into passworded directories. To attach to a
passworded directory, you would type something similar to this:

OK, a ‘dirname password’

Notice how you followed the directory name with the password and enclosed the
entire deal with quotes. If you were going to attach to a passworded sub-UFD
you might type something like this:

OK, a ‘primenet*>info>source password’

Passworded directories can be a pain in the ass, but, unlike ACL’s, they can be
gotten around. Look inside CPL programs (by SLISTing them) for occurrances of
ATTACH statements enclosed in single quotes. Thats about all the internal sec-
urity in PRIMOS up to the current revision level (22.0.0).

_______________________________________________________________________________

EXPLORING THE VAST REACHES OF A PRIME

When looking around a Prime, always start in your initial attach UFD. Check
out every file in it and every file in sub-UFD’s under it. When finished there
cruise on up to MFD 0 and start down-attaching to the many UFD’s there and look
at everything. SLIST all SAM files, read all mail, look at EVERYTHING. Leave
no UFD un-attached to! Leave no file un-read.

Understandably it will take a good few hours (sometimes as many as 12) to fully
investigate a Prime, but believe me, it is worth it. Capture everything that
looks valuable to your buffer. When done looking, follow up everything you
captured.

Well, that about wraps up Part II of this series. Look forward to lots of use-
ful information regarding the myriad of PRIMOS applications in the next part of
this series. Just some of the information in the next part will be:

o Using EDIT_PROFILE to create and modify accounts
o The DSM (Distributed System Management) utilities
o Using the myriad of MAIL utilities
o Editing and Uploading text via the ED text editor

Until then may the forces of darkness become confused on the way to your house.

_______________________________________________________________________________

End of Part II of the “Introduction to the PRIMOS Operating System”
_______________________________________________________________________________

Introduction to Trusted Computer System Evaluation Criteria

NCSC TECHNICAL REPORT – 005

Volume 2/5

Library No. S-243,039

FOREWARD

This report is the second of five companion documents to the Trusted Database Management
System Interpretation of the Trusted Computer System Evaluation Criteria. The companion
documents address topics that are important to the design and development of secure database
management systems, and are written for database vendors, system designers, evaluators, and
researchers. This report addresses entity and referential integrity issues in multilevel secure
database management systems.

ACKNOWLEDGMENTS

The National Computer Security Center extends special recognition to the authors of this
document. The initial version was written by Vinti Doshi and Sushil Jajodia of the MITRE
Corporation. The final version was written by Bill Wilson and Stan Wisseman of Arca Systems,
Inc.

The documents in this series were produced under the guidance of Shawn P. O’Brien of the
National Security Agency, LouAnna Notargiacomo and Barbara Blaustein of the MITRE
Corporation, and David Wichers of Arca Systems, Inc.

We wish to thank the members of the information security community who enthusiastically gave
of their time and technical expertise in reviewing these documents and in providing valuable
comments and suggestions.

TABLE OF CONTENTS

SECTION PAGE

1.0 INTRODUCTION 1

1.1 BACKGROUND AND PURPOSE 1

1.2 SCOPE 1

1.3 INTRODUCTION TO ENTITY AND REFERENTIAL INTEGRITY 2

1.4 AUDIENCES OF THIS DOCUMENT 3

1.5 ORGANIZATION OF THIS DOCUMENT 4

2.0 BACKGROUND 5

2.1 BASIC CONCEPTS OF ENTITY AND REFERENTIAL INTEGRITY 6

2.2 REFERENTIAL INTEGRITY RULES 10

2.2.1 DELETE 10

2.2.2 UPDATE of Referenced Relation 13

2.2.3 NSERT or UPDATE of Referencing Relation 17

2.2.4 Additional Rules 17

2.3 PROBLEMS WITH REFERENTIAL INTEGRITY CONSTRAINTS 17

3.0 ENTITY AND REFERENTIAL INTEGRITY IN MLS DATABASES 18

3.1 RELATED TCSEC REQUIREMENTS 18

3.2 BASIC CONCEPTS IN MULTILEVEL RELATIONS 19

3.3 THE CONCEPT OF PRIMARY KEY IN MULTILEVEL RELATIONS 21

3.4 ENTITY INTEGRITY IN MULTILEVEL RELATIONS 21

3.5 REFERENTIAL INTEGRITY IN MULTILEVEL RELATIONS 22

3.6 ENFORCEMENT OF INTEGRITY CONSTRAINTS 25

4.0 COVERT CHANNELS 27

4.1 PRIMARY KEY UNIQUENESS 27

4.2 ENFORCEMENT OF REFERENTIAL INTEGRITY RULES 28

4.2.1 Enforcement of Integrity Rules When C[FK] = C[PK] 29

4.2.2 Enforcement of Integrity Rules When C[FK] > C[PK] 30

4.3 RELATION TO DBMS ARCHITECTURE 36

5.0 SUMMARY 38

REFERENCES 39

LIST OF FIGURES

FIGURE PAGE

2.1: RELATION SOD 6

2.2: RELATION PS 8

2.3: REFERENTIAL CONSTRAINTS IN RELATIONS PR, PS, AND SOD 9

2.4: RELATIONS SOD AND PS AFTER STARSHIP = “APOLLO” IS DELETED
UNDER THE CASCADES-DELETE RULE 11

2.5: RELATIONS SOD AND PS AFTER STARSHIP = “APOLLO” IS
DELETED UNDER THE NULLIFIES-DELETE RULE 12

2.6: RELATIONS SOD AND PS AFTER STARSHIP = “ENTERPRISE” IS
UPDATED TO THE VALUE “USS ENTERPRISE”
UNDER THE CASCADES-UPDATE RULE 15

2.7: RELATIONS SOD AND PS AFTER STARSHIP = “ENTERPRISE” IS
UPDATED TO THE VALUE “USS ENTERPRISE” UNDER THE
NULLIFIES-UPDATE RULE 16

3.1: DIFFERENT SOD VIEWS BASED ON ACCESS CLASS 21

3.2: TYPICAL RELATION INSTANCES FOR SOD AND PS 23

3.3: UNCLASSIFIED INSTANCES OF PS AND SOD RELATIONS 24

4.1: SOD AFTER INSERTION OF TUPLE CORRESPONDING TO
STARSHIP = “VOYAGER” BY UNCLASSIFIED USER 28

4.2: RELATION PS AND SOD WHEN C[FK] = C[PK] 30

4.3: RELATIONS SOD AND PS WITHOUT POLYINSTANTIATION 32

4.4: RELATIONS WITH TUPLE-LEVEL GRANULARITY 34

4.5: RELATIONS WITH ATTRIBUTE-LEVEL GRANULARITY 35

LIST OF TABLES

TABLE PAGE

4.1: SUMMARY OF COVERT CHANNELS IN REFERENTIAL INTEGRITY
RULES 36

SECTION 1

INTRODUCTION

This document is the second volume in the series of companion documents to the Trusted Database
Management System Interpretation of the Trusted Computer System Evaluation Criteria [TDI 91;
DoD 85]. This document examines entity and referential integrity issues in multilevel secure
(MLS) database management systems and summarizes the research to date in these areas.

1.1 BACKGROUND AND PURPOSE

In 1991 the National Computer Security Center published the Trusted Database Management
System Interpretation (TDI) of the Trusted Computer System Evaluation Criteria (TCSEC). The
TDI, however, does not address many topics that are important to the design and development of
secure database management systems (DBMSs). These topics (such as inference, aggregation, and
database integrity) are being addressed by ongoing research and development. Since specific
techniques in these topic areas had not yet gained broad acceptance, the topics were considered
inappropriate for inclusion in the TDI.

The TDI is being supplemented by a series of companion documents to address these issues
specific to secure DBMSs. Each companion document focuses on one topic by describing the
problem, discussing the issues, and summarizing the research that has been done to date. The intent
of the series is to make it clear to DBMS vendors, system designers, evaluators, and researchers
what the issues are, the current approaches, their pros and cons, how they relate to a TCSEC/TDI
evaluation, and what specific areas require additional research. Although some guidance may be
presented, nothing contained within these documents should be interpreted as criteria.

These documents assume the reader understands basic DBMS concepts and relational database
terminology. A security background sufficient to use the TDI and TCSEC is also assumed;
however, fundamentals are discussed whenever a common understanding is important to the
discussion.

1.2 SCOPE

This document addresses entity and referential integrity issues in multilevel secure DBMSs. It is
the second of five volumes in the series of TDI companion documents, which includes the
following documents:

· Inference and Aggregation Issues in Secure Database Management Systems [Inference
96]

· Entity and Referential Integrity Issues in Multilevel Secure Database Management
Systems

· Polyinstantiation Issues in Multilevel Secure Database Management Systems [Poly 96]

· Auditing Issues in Secure Database Management Systems [Audit 96]

· Discretionary Access Control Issues in High Assurance Secure Database Management
Systems [DAC 96]

This series of documents uses terminology from the relational model to provide a common basis
for understanding the concepts presented. For most of the topics covered in this series the concepts
presented should apply to most database modeling paradigms, depending on the specifics of each
model. For the entity and referential integrity constraints discussed in this document, however,
there are important differences between different models. This is because the primary keys in a
relational DBMS represent both unique identifiers for tuples and values of attributes in the tuple.
They must be protected in accordance with the sensitivity of the data they represent and this can
interfere with their role as a unique identifier of tuples. By contrast, the object identifier (OID) in
an Object-Oriented DBMS is not a property or attribute of the object it identifies, and does not
represent a user-visible data value. Khoshafian and Copeland provide a useful taxonomy of
different ways of specifying object identity including the techniques used in relational and Object-
Oriented DBMSs [Khoshafian 86]. Similarly, in a relational DBMS, foreign keys represent data
values and serve as pointers to other tuples. In an Object-Oriented DBMS, pointers to other objects
are not used to store data values, but rather to represent the inclusion of one object within another.
As in relational databases, problems may occur if a reference is deleted and some references remain
in objects. The implications of these distinctions for enforcement of secrecy in an Object-Oriented
DBMS require further research. This document specifically addresses relational DBMSs.

This document is related to the companion documents Inference and Aggregation Issues in Secure
Database Management Systems and Polyinstantiation Issues in Multilevel Secure Database
Management Systems. Much of the discussion of the relationship between enforcement of integrity
constraints and multilevel security centers on the potential inference channels which integrity
constraints can introduce. One way to avoid these channels for entity integrity is to use
polyinstantiation. This is discussed later in more detail.

1.3 INTRODUCTION TO ENTITY AND REFERENTIAL INTEGRITY

Secrecy and integrity are two key concepts in the community of database security researchers and
users. Secrecy refers to the protection or safety of the data against unauthorized disclosure, and
integrity refers to the unauthorized alteration or destruction of data. In the wider database research
community, integrity refers more generally to the correctness, accuracy, and internal consistency
of data.

Preserving the accuracy of information is extremely important rn any database. In the relational
model, one way in which accuracy of information is preserved is by preventing updates that violate
integrity constraints. Entity integrity and referential integrity are two of the most important
integrity constraints. They are defined on relations and are enforced by the DBMS.

Entity integrity states that no primary key attribute of a relation is allowed to have null values. In
addition, the primary key must have a unique value. These properties of a primary key correspond
to the fact that entities in the real world are distinguishable (i.e., they have a unique identification
of some kind). In the relational model, the primary key performs the function of unique
identification. Referential integrity is an interrelation integrity constraint. In general, referential
integrity defines existence relationships between entities in a database that need to be maintained
by the DBMS. This document defines these integrity constraints formally and presents their
importance in the context of security in detail.

In multilevel applications, data are classified to control disclosure. It is important to realize the
necessary trade-off to be made between secrecy and integrity because of the challenges in
enforcing integrity constraints across multiple secrecy levels without disclosure of information.
This document defines entity and referential integrity for a standard relational DBMS and then
presents methods for resolving the inherent integrity/secrecy conflict in an MLS environment.

1.4 AUDIENCES OF THIS DOCUMENT

This document is targeted at four primary audiences: the security research community, database
application developers/system integrators, trusted product vendors, and product evaluators. In
general, this document is intended to present a framework for understanding the nature of entity
and referential integrity policies or requirements and how they conflict with the need to enforce an
access control policy. This framework is used to describe the research that has been done to date
and the approaches they present for providing solutions. Each of the specific audiences should
expect to get the following from this document:

Researcher

This document describes the basic problems in simultaneously enforcing integrity constraints and
MAC. Some important research contributions are discussed as various topics are covered. Related
research on other aspects of integrity and the relationship to secrecy is discussed in Section 3.6.
For additional relevant work, the researcher should consult two other companion documents,
Inference and Aggregation Issues in Secure Database Management Systems [Inference 96] and
Polyinstantiation Issues in Multilevel Secure Database Management Systems [Poly 96].

Database Application Developer/System Integrator

This document describes various entity and referential integrity facilities which could be provided
by an MLS DBMS. It discusses the implications of these facilities relative to the tradeoffs involved
in meeting a system’s requirements for secrecy and integrity.

Trusted Product Vendor

This document describes the conflicts between Mandatory Access Controls (MAC) and multilevel
entity and referential integrity constraints. It then discusses approaches to entity and referential
integrity enforcement in an MLS database and the benefits and drawbacks of these approaches. In
particular, it considers how the issues with enforcement of entity and referential integrity
constraints in an MLS database relate to the TCSEC access control and covert channel
requirements. This is discussed in the context of tuple level as well as element level labeling. This
document will provide a framework for understanding specific requirements interpretations as they
are developed by the National Computer Security Center.

Evaluator

This document describes access control and covert channel issues related to entity and referential
integrity. It provides a framework for analyzing specific vendor mechanisms and understanding
Technical Review Board/Interpretations Working Group decisions.

1.5 ORGANIZATION OF THIS DOCUMENT

The organization of the remainder of this document is as follows:

· Section 2 gives the definitions of entity and referential integrity with respect to single-level
DBMSs and describes various important concepts related to referential integrity.

· Section 3 defines the basic concepts of entity and referential integrity with respect to
multilevel relations.

· Section 4 discusses the issues associated with covert channels related to enforcing entity
and referential integrity constraints.

· Section 5 presents conclusions.

SECTION 2

BACKGROUND

Entity integrity and referential integrity are two basic integrity requirements in a relational DBMS
(RDBMS). They help prevent incorrect data from being entered into the database. Entity integrity
guarantees a unique representation of each entity in the database through specification of primary
key attributes for each relation. Referential integrity assures that if any references exist between
two or more entities, then the related entities do exist in the database. Referential integrity places
restrictions on foreign key attributes.

Referential integrity is one of the most important interrelation integrity constraints for the
relational data model. Although its basic concepts have been discussed over the past ten years, a
successful referential integrity capability for a RDBMS is still a challenging implementation
problem. While referential integrity appears to be a simple concept, the operational definitions that
appear in the literature are imprecise and lead to a host of anomalies.

A standard relational database can be perceived by its users as a collection of relations. A relation
has well-defined mathematical properties and is used to store data. Each relation has two parts:

1. A state-invariant relation schema R (A1, A2, …, An), where each Ai is an attribute over
some domain Di, 1 £ i £ n, which is a set of acceptable values for Ai.

2. A state-dependent relation R over R, which is a set of distinct tuples of the form (a1, a2…,
an), where each element ai; is a value in domain di, 1 £ i £ n.

The following notation and conventions are used throughout this document. In definitions, relation
schemes are denoted in bold fonts (such as R, R1, R2), and the corresponding relations are denoted
using plain fonts (such as R, R1, R2). However, when clear in specific examples, the same symbol
is used to denote the relation schema, as well as the corresponding relation. Let X denote one or
more attributes of a relation R. If t is a tuple in a relation R, t [X] denotes the projection of t onto X.

This section first defines entity and referential integrity, followed by terminology related to these
concepts. The examples make use of Structured Query Language (SQL) syntax [ANSI 92, 94]. The
section then gives various rules for enforcing referential integrity and discusses the problems
associated with referential integrity in single-level relational databases. From this understanding
of integrity, we can then better discuss the conflict with enforcement of a MAC policy in Section 3.

2.1 BASIC CONCEPTS OF ENTITY AND REFERENTIAL INTEGRITY

Before defining entity integrity, it is necessary to define the concept of a primary key.

In simple terms, the primary key of a relation is just a unique identifier of each tuple in the relation.
More precisely, a primary key for a relation R is a set of attributes PK with the following
properties:

1. The value of PK uniquely identifies each tuple in the relation R. That is, for any state of
R, and any tuples t1 and t2, if t1[PK] = t2[PK] then t1 = t2.

2. PK is minimal. That is, there is no proper subset of PK satisfying property 1.

It is possible there is more than one set of attributes satisfying these properties. Any such set is
called a candidate key. Precisely one candidate must be chosen and designated as the primary key
of R.

Example 1. Consider the relation schema SOD (Starship, Objective, Destination), which contains
for each starship its name (Starship), the purpose of the flight (Objective), and its destination
(Destination). An example relation for relation schema SOD is given in Figure 2.1.

STARSHIP

OBJECTIVE

DESTINATION

Enterprise

Exploration

Talos

Voyager

Spying

Mars

Apollo

Exploration

Moon

Saratoga

Mining

Moon

Figure 2.1: Relation SOD

Since the attribute Starship uniquely identifies each tuple of the relation SOD, it is a candidate key
of the relation SOD. As Starship is the only candidate key of the relation SOD, it is also the primary
key of relation SOD.

In SQL syntax, the attribute(s) constituting the primary key can be specified when a relation
schema is created, as the following shows:

CREATE TABLE SOD

(Starship CHAR(20) NOT NULL,

Objective CHAR(15),

Destination CHAR(10),

PRIMARY KEY (Starship))

Notice that the ANSI syntax uses the term “TABLE” instead of the term “relation” used in this
document.

The entity integrity constraint requires that all attribute values of the primary key be defined for
each tuple.

Entity Integrity: If PK is the primary key for relation R, then for all states of R, for every tuple
t in R and every attribute A in PK, t[A] is not null.

A foreign key provides a basis for a tuple to refer to another tuple. Let R1 and R2 be two relation
schemas, and let R1 and R2 denote the respective relations corresponding to these schemas.

Referential Integrity: Let PK denote the primary key of R2, and let FK denote one or more
attributes of the relational schema R1. FK is said to be a foreign key of R1 referencing R2 if
given any tuple t1 in R1, the following two requirements are met:

1. t1 [FK] is either wholly null or wholly non-null, and

2. Whenever t1[FX] is non-null, there is a tuple t2 in R2 such that t1[FK] = t2[PK].

Here R1 is the referencing relation and R2 is the referenced relation. Sometimes PK is referred to
as the target value of the foreign key FK. Notice that R1 and R2 need not be distinct.

Example 2. In addition to the relation schema SOD given in Example 1, consider the relation
schema PS (Person_Name, Starship), which contains the name of the employee (Person_Name)
and the name of the ship assigned to the employee (Starship). An example relation for PS is given
in Figure 2.2.

Suppose Person_Name uniquely identifies each employee in the PS relation, then Person_Name
becomes the primary key for the relation schema PS. If Starship is declared a foreign key for PS
with the relation schema SOD as the referenced relation, a DBMS that supports referential integrity
will automatically ensure that whenever an employee is assigned a (non-null) ship, there is a
matching tuple in the relation schema SOD with an identical value for the attribute Starship.

Notice that employee Mr. Spock, given in Figure 2.2, has not been assigned any starship. It seems
from the definition of the PS relation that nulls are allowed. In some applications it may be
desirable to prohibit this situation (i.e., every employee must be assigned a starship). The
referencing relation’s schema definition can specify whether or not the foreign key attribute can
assume a null value.

Using SQL syntax, foreign keys can be specified as follows:

CREATE TABLE PS

Person_Name CHAR(15) NOT NULL,

Starship CHAR(20),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship)).

PERSON_NAME

STARSHIP

James Kirk

Enterprise

Mr. Spock

Tim McKelley

Apollo

Figure 2.2: Relation PS

It follows from the definition of the foreign key that there is an identical matching primary key
value in the referenced relation for every foreign key value in the referencing relation. It is
important to maintain the integrity between the referencing values (foreign key values) and the
referenced values (primary key values).

Example 3. Consider the relation schema PR (Person_Name, Rank), which contains the employee
name (Person_Name) and the rank of the employee (Rank). Person_Name is the primary key for
the relation schema. Person_Name is also the foreign key referring to relation schema PS.

The relation schema PR can be expressed in SQL as follows:

CREATE TABLE PR

(Person_Name CHAR(20) NOT NULL,

Rank CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Person_Name) REFERENCES PS (Person Name))

Here, the relation schema PR references the relation schema PS given in Example 2. In addition,
the relation schema PS in Example 2 references the relation schema SOD. Since there is a
referential constraint from PR to PS, and also from PS to SOD, relation schema PS becomes both
a referencing relation and a referenced relation, see Figure 2.3.

Figure 2.3: Referential Constraints in Relations PR, PS, and SOD

This can be depicted as a referential path from PR to SOD as follows:

PR > PS > SOD

Referential Cycles: Closed referential paths, or referential paths that point back to the starting
relation, are referred to as referential cycles. In general, the referential cycle including n
relations (where n > 1) can be represented as follows [Date 86, 90]:

Rn > Rn-1 > Rn-2 > … > R2 > R1 > Rn.

Referential cycles are of interest since they can cause insertion problems. In the presence of
referential cycles, it is necessary that one of the following constraints be true; otherwise, it is
impossible to insert the first tuple in any or each of the relations:

1. One of the foreign keys in the referential cycle must be allowed to have a null value, or

2. The constraint check should be done only at the end-of-transaction (i.e., when the
transaction commits).

A self-referencing relation is a special case of a referential cycle that includes exactly one relation:
a relation can have multiple foreign keys corresponding to different relations.

Some important concepts related to the terms defined in this section can be summarized as follows:

· A primary key of a relation cannot have a null value in any tuple within that relation (entity
integrity) and each primary key must be unique (property of a primary key).

· Foreign keys can have null values. For example, in Figure 2.2 the employee Mr. Spock has
not been assigned any starship as yet; therefore, the Starship value for Mr. Spock is null.
(Note: If in a specific instance it is desired to prohibit null values for foreign keys, this can
be done by using a NOT NULL clause for the attributes in the foreign key when the
relation is created.)

· For referential integrity, every non-null value of a foreign key must be matched by an
identical primary key value in the referenced relation. But the converse need not be true;
for example, starship Saratoga in Figure 2.1 has no employee assigned to it in Figure 2.2.

· A relation can be a referenced relation, as well as a referencing relation.

2.2 REFERENTIAL INTEGRITY RULES

Whenever two or more relations are related through referential constraints, it is necessary that
references be kept consistent in the face of insertions, deletions, and updates to these relations. Date
identifies several actions which can be taken to maintain consistency of references [Date 90].
Exactly which action is chosen for a particular relation depends on the behavior desired by the
underlying application. These possible actions are discussed in the following subsections.

2.2.1 DELETE

When the target of a foreign key is deleted it could result in a dangling reference. Some action is
needed to make sure this does not happen. Four options that may be specified for the referenced
relation are RESTRICTED-delete, CASCADES-delete, NULLIFIES-delete, and SET
DEFALILT-delete. Each of these is explained in turn.

RESTRICTED-delete

If the RESTRICTED-delete option is specified, the primary key value in the referenced relation
cannot be deleted as long as there exists at least one matching foreign key value in the referencing
relation. The deletion of the referenced value is restricted to the case where there is no
corresponding referencing value in the referencing relation.

For instance, suppose an attempt is made to delete the starship Apollo from the relation SOD. Since
the referencing relation PS refers to the relation SOD through the attribute Starship, under the
RESTRICTED-delete rule, this deletion cannot be performed as there is a tuple in PS referencing
starship Apollo. The delete is denied and the two relations would remain unchanged.

The syntax for specifying the RESTRICTED-delete rule may be given as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON DELETE RESTRICT)

CASCADES-delete

Under the CASCADES-delete option, whenever the target tuple of a foreign key is deleted, all
referencing foreign key tuples are also deleted. In the previous example, if an attempt is made to
delete the starship Apollo from the relation SOD, the delete would be cascaded to the relation PS
and the employee tuples referencing the starship Apollo would also be deleted. After such a
CASCADES-delete operation, the relations SOD and PD would change to the form given in Figure
2.4.

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise

Exploration

Talos

Voyager

Spying

Mars

Saratoga

Mining

Rigel

PS

PERSON_NAME

STARSHIP

James Kirk

Enterprise

Mr. Spock

Figure 2.4: Relations SOD and PS after Starship = “Apollo” is Deleted under the
CASCADES-Delete Rule

In SQL, the CASCADES-delete rule can be specified as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON DELETE CASCADE)

NULLIFIES-delete

Whenever the NULLIFIES-delete option is specified for a foreign key, the referencing foreign key
attribute values will be set to a null value when the tuple containing the referenced value is deleted.
In the example given earlier, when starship Apollo is deleted, the foreign key value, for all tuples
referencing Apollo in relation PS, is set to null. The new state of the relations is as shown in Figure
2.5.

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise

Exploration

Talos

Voyager

Spying

Mars

Saratoga

Mining

Rigel

PS

PERSON_NAME

STARSHIP

James Kirk

Enterprise

Mr. Spock

Tim McKelley

Figure 2.5: Relations SOD and PS after Starship = “Apollo” is Deleted under the
NULLIFIES-Delete Rule

Before setting the referencing value to null, it is important to make sure that the relation schema
allows a null value for the foreign key attribute. Otherwise, there will be a conflict.

The NULLIFIES-delete rule can be expressed in SQL as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON DELETE SET NULL)

SET DEFAULT-delete

The SQL2 [ANSI 92] and SQL3 [ANSI 94] standards provide yet another referential action for the
delete operation, called SET DEFAULT. This option is similar to the NULLIFIES delete rule
given above. The only difference is that the SET DEFAULT option contains a default clause that
specifies the default value for the attribute. The default value may be a null or a non-null value. If
the referential action specifies the SET DEFAULT option, then each referencing attribute is
defined by an implicit or explicit default clause. If the default value is null, then SET DEFAULT
is equivalent to a SET NULL.

The SQL syntax for the SET DEFAULT-delete rule is as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON DELETE SET DEFAULT < option>)

The default option is specified in the

2.2.2 UPDATE of Referenced Relation

Changing the primary key values in a referenced relation could violate referential integrity unless
appropriate action is taken. There are different options which can be specified for the referencing
relation whenever an update is made to the target primary key values of a referenced relation. The
possible options are RESTRICTED-update, CASCADES-update, NULLIFIES-update, or SET
DEFAULT-update.

RESTRICTED-update

Under the RESTRICTED-update option, an update to the target primary key values of a referenced
relation cannot be made as long as there exists at least one matching foreign key value in the
referencing relation. The update to the referenced tuple is restricted to the case where there are no
matching referencing tuples.

As an example, suppose an attempt is made to update the name of the starship from Enterprise to
USS Enterprise in relation SOD shown in Figure 2.1. As there is an employee assigned to the ship,
the update is rejected. The relations SOD and PS remain unchanged, and look like Figures 2.1 and
2.2.

The syntax for specifying the RESTRICTED-update option may be specified as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON UPDATE RESTRICT)

CASCADES-update

If the CASCADES-update option is specified for a referencing relation, whenever an update is
made to the referenced attribute, all changes are cascaded to the matching referencing attributes.
This means that whenever the target value of a foreign key is modified, all referencing foreign key
values are also similarly modified. Consider the example where an attempt is made to update the
name of the starship from Enterprise to USS Enterprise in the relation schema SOD. Under
CASCADE-update, the update is cascaded to the matching referencing tuples in the relation
schema PS. For the employee assigned to starship Enterprise, the name is updated to USS
Enterprise. The new state of the two relations SOD and PS is shown in Figure 2.6.

In SQL, the CASCADE-update option can be expressed as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON UPDATE CASCADE)

SOD

STARSHIP

OBJECTIVE

DESTINATION

USS Enterprise

Exploration

Talos

Voyager

Spying

Mars

Apollo

Exploration

Moon

Saratoga

Mining

Rigel

PS

PERSON_NAME

STARSHIP

James Kirk

USS Enterprise

Mr. Spock

Null

Tim McKelley

Apollo

Figure 2.6: Relations SOD and PS after Starship = “Enterprise” is Updated to the Value
“USS Enterprise” under the CASCADES-Update Rule

NULLIFIES-update

Under the NULLIFIES-update option, the referencing foreign key attribute values are set to null
whenever the target primary key values in the referenced relation are updated. In the example given
earlier, when the name of the starship is updated from Enterprise to USS Enterprise, the Starship
for the employee assigned to Enterprise is set to null. The new state of the relations is shown in
Figure 2.7.

Before setting the referencing value to null, it is important to make sure that the schema definition
allows a null value for the foreign key attribute. If the nulls rule does not allow a null value, then
there will be a conflict between the two integrity rules.

The NULLIFIES-update rule is expressed in SQL syntax as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(I5),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON UPDATE SET NULL)

SOD

STARSHIP

OBJECTIVE

DESTINATION

USS Enterprise

Exploration

Talos

Voyager

Spying

Mars

Apollo

Exploration

Moon

Saratoga

Mining

Rigel

PS

PERSON_NAME

STARSHIP

James Kirk

< null >

Mr. Spock

< null >

Tim McKelley

Apollo

Figure 2.7: Relations SOD and PS after Starship = “Enterprise” is Updated to the Value
“USS Enterprise” under the NULLIFIES Update Rule

SET DEFAULT-update

SQL2 and SQL3 define another referential constraint for update, which is SET DEFAULT. If the
referential constraint specifies the SET DEFAULT option, then each referencing attribute is
defined by an implicit or explicit default clause. The default clause specifies the default value for
the attribute, and the default value may be a null or a non-null value. If the default value is null,
then the SET DEFAULT option can be considered equivalent to the NULLIFIES update rule.

The SQL syntax for the SET DEFAULT-update rule is as follows:

CREATE TABLE PS

(Person_Name CHAR(20) NOT NULL,

Starship CHAR(15),

PRIMARY KEY (Person_Name),

FOREIGN KEY (Starship) REFERENCES SOD (Starship),

ON UPDATE SET DEFAULT

The default option is specified in the

2.2.3 INSERT or UPDATE of Referencing Relation

When a tuple is inserted into a relation with a foreign key or a tuple in the relation is updated, the
insertion (or update) of a foreign key value should be in accordance with referential integrity. Each
foreign key value must be NULL or have an identical matching primary key value in the referenced
relation. This requirement can be enforced by disallowing the insert (or update) unless the
condition is met or by setting the foreign key to a default value or null (if nulls are allowed) when
the condition is not met.

2.2.4 Additional Rules

In spite of the many integrity rules discussed in this section, the rules above are not exhaustive.
Additional options include conversation with the end user and transferring information to some
other files. For instance, an additional option in SQL3 is the PENDANT specification, which
implies that each primary key value in the referenced relation is the same as some foreign key value
in the referencing relation. For example, if the referential constraint for the relation EMP is as
shown below, then as soon as the last employee in a particular department is deleted, the
department will also be deleted.

FOREIGN KEY (Starship) REFERENCES [PENDANT] SOD(Starship)

2.3 PROBLEMS WITH REFERENTIAL INTEGRITY CONSTRAINTS

Referential integrity plays a major role in RDBMSs where it is employed to express existence
dependencies. The concept of referential integrity seems to be simple, but it has been a topic of
discussion for the past several years [Markowitz 90; Horowitz 92]. The operational definitions are
not precise and, therefore, lead to some anomalies. Confusion surrounds both the concept itself and
its implementation in RDBMSs. There is a need to carefully examine the data manipulation
problems caused by certain referential integrity structures and to find ways to avoid these
problems.

In a RDBMS, a single update or delete can affect multiple tuples through the application of
referential integrity rules (e.g., cascading deletes or updates). It is necessary for these processes to
be deterministic. In other words, the final state of the database should be a function of the initial
state of the database, and the specific statement to be executed. At times, certain referential
constraints associated with relations may block update or deletion of some tuples because of
conflicting referential constraint specifications, thus making the outcome of the update or delete
statement unpredictable. Some of the problems that have been identified are dependency on the
order in which referential integrity constraints are applied, referential cycles, and dependency on
the order in which the tuples are processed in response to a query. Discussion of these problems in
detail is outside the scope of this document.

SECTION 3

ENTITY AND REFERENTIAL INTEGRITY IN MLS DATABASES

Before entity and referential integrity can be defined for multilevel relations, it is necessary to
extend the basic concepts of classical (single-level) relations to the multilevel context. In MLS
databases, data are assigned different security levels and each user is assigned a clearance level.
Each user can only access data they are cleared for based on the user’s security clearance. As a
consequence the meaning of relations becomes more complicated in the multilevel world, and
there is no clear consensus regarding the exact definition of a multilevel relational model.

To develop an MLS database, it is necessary to (1) define a security policy, (2) develop
mechanisms that support the policy, and (3) get the necessary assurance that the system developed
is secure. This section first reviews the basic concepts for the multilevel relational data model, then
defines entity and referential integrity constraints for multilevel relations.

3.1 RELATED TCSEC REQUIREMENTS

The TCSEC imposes two types of requirements which affect how entity and referential integrity
can be enforced in a DBMS targeted to meet the TCSEC requirements at B1 and above. A DBMS
targeted for Class B1 or above must enforce a MAC policy over all subjects and storage objects it
controls. This places requirements on the sensitivity labels of elements of primary and foreign keys
and on the relationships between sensitivity levels of foreign keys and the primary keys they
reference. For a DBMS targeted at Class B2 or above, the TCSEC requires a thorough search for
covert channels (storage channels only at Class B2). In the multilevel context, enforcement of the
uniqueness of primary keys and enforcement of referential integrity can create significant covert
channels. Guidelines on acceptable bandwidths for covert channels are given in Section 8 of the
TCSEC. This section specifically addresses the implications of direct enforcement of MAC
controls (as required at B1 and above). The implications of integrity enforcement on covert
channels is covered in Section 4. A determination of precisely which approaches to enforcing
entity and referential integrity will be considered compliant with the TCSEC requirements will
evolve over time as the Evaluation Community publishes official interpretations on this subject.
However, with the successful evaluation of Trusted Oracle7 DBMS MAC Mode with an
unmodified integrity mechanism, precedence has been set for Class B1 DBMSs [Oracle 94].

3.2 BASIC CONCEPTS IN MULTILEVEL RELATIONS

The basic model for multilevel relations needs to be defined with a MAC policy in mind. The MAC
policy for MLS databases is often based on the Bell-LaPadula model [Bell 76], which is stated in
terms of subjects and objects. A subject is an active entity, such as a process that can request access
to objects, whereas an object is a passive entity, such as a record, a file, or a field within a record.
Every subject is assigned a clearance level and every object a classification level. Classification
levels and clearances are collectively referred to as security levels, and form a lattice. Each security
level has two components: a hierarchical component and a set (possibly empty) of unordered
categories. A security level c1 is said to dominate security level c2, in the partial order, if (1) the
hierarchical component of c1 is greater than or equal to that of c2, and (2) all categories in c2 are
included in those of c1. A security level c1 strictly dominates security level c2, in the partial order,
if (1) c1 dominates c2, and (2) c1 does not equal c2. The following are two necessary conditions in
the Bell-LaPadula model [Bell 76; DoD 85]:

1. The Simple Security Condition or “No Read Ups”: A subject can only read objects at a
security level dominated by the subject’s level, and

2. The *-Property (Star Property) or “No Write Downs”: A subject can only write objects
at a security level that dominates the subject’s level.

To apply these concepts to a DBMS it is necessary to determine the granularity of the objects
protected by MAC, i.e., the storage objects. Security levels are then associated with these storage
objects. Work on MLS databases has focused on four choices for assigning security levels to data
stored in a relation. One can assign security levels to entire relations, to individual tuples (rows) of
a relation, to individual attributes (columns) of a relation, or to individual elements of a relation.
In the definitions below, the most general case is considered, in which security levels are assigned
to individual data elements stored in relations. However, since tuple level labeling is used in all
DBMS products evaluated to date, the concepts are also considered in the (simplified) context of
tuple level labeling.

A relation schema in the multilevel context not only contains all its data attributes, but also includes
the corresponding security level for each data attribute. Formal definitions of a multilevel relation
schema and multilevel relations are as follows [Denning 87]:

Relation Schema: A multilevel relation schema has the following form:

R(A1, C1, A2, C2, … , An, Cn).

Each Ai is a data attribute over some domain Di and Ci is the classification attribute of Ai. The
domain of Ci, i = 1, …,n is some set consisting of security levels.

If tuple level labeling is used, there will only be one classification attribute for the entire tuple:

R(A1, A2, … , An, C).

For a multilevel logical relation schema R, there is a corresponding relation Rc per security level
in the security lattice. A user having a clearance at a security level c sees the relation Rc, which
contains data at security level c or below. More formally,

Relations: A relation at a security level c has the following form:

Rc(A1, C1, A2, C2, … , An, Cn)

Rc consists of a set of tuples of the form (a1, c1, a2, .2…. ,an, cn), where each ai lies in the domain
Di or ai is null, c > ci, ci, i = 1 … ,n. Even if ai is null, its classification attribute ci is never null.

When an attribute value ai is null, there are two reasonable possibilities for the corresponding
security level value: ci could be assigned a value that is identical to c, or the security level of the
attributes constituting the primary key. In this document, ci would be assigned a value consistent
with the second possibility.

If the security level of the primary key value is not dominated by c in a tuple, then that tuple is not
shown in Rc at all. If the security level of the primary key value is dominated by c, then that tuple
is shown in Rc; however, any attribute value with a security level not dominated by c, is shown
having a null value with the corresponding security level the same as that of the primary key value.

For tuple level labeling, Rc consists of those tuples whose security level is dominated by c.

These concepts can be better explained with the help of an example taken from [Jajodia 91].

Example 4. Consider the relation schema SOD given in Example 1. Starship is the primary key of
the relation schema SOD, and the security levels are assigned at the granularity of individual data
elements. The hierarchical order usually followed is Top Secret (TS), Secret (S), Confidential (C),
and Unclassified (U). A user with a Secret clearance will see the entire multilevel relation SODS,
while a user with an Unclassified clearance will see the Unclassified instance SODU as shown in
Figure 3.1.

SODS

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration U

Talos U

Voyager U

Spying S

Mars S

SODU

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration

Talos U

Voyager U

U

Figure 3.1: Different SOD Views Based on Access Class

3.3 THE CONCEPT OF PRIMARY KEY IN MULTILEVEL RELATIONS

The notion of a primary key is a fundamental concept in the world of single-level relational
databases. The primary key is used to maintain integrity of relations, it is used during the database
design, and it is also used for storage and retrieval purposes. The primary key for a single-level
relation must satisfy the uniqueness property and the minimality property, as discussed in Section
2.1. Entity integrity requires that the primary key serves as a unique identifier of each tuple in the
relation and that it does not contain a null value. The uniqueness property can create covert
channels as discussed in Section 4. One approach to avoiding these channels involves augmenting
the user-defined primary key with security level attributes associated with the primary key
attributes. However, in the remainder of this document it is assumed that there is a user-specified
primary key consisting of a subset of the data attributes and not including the security level
[Denning 87]. It is called the apparent primary key of the multilevel relation schema.

3.4 ENTITY INTEGRITY IN MULTILEVEL RELATIONS

A relation schema R will be assumed to have a user-defined apparent primary key consisting of
one or more data attributes of R. It will be denoted by PK. The entity integrity property of the
standard relational model can be extended to the multilevel environment by defining the three
requirements given below, which are applicable only to element level classification [Denning 87].
The three requirements are automatically met for tuple level classification.

The first requirement is the same as for the standard relational model, that no tuple in an Rc have
a null value for any attribute in PK. The second requirement states that the PK values should be
uniformly classified; otherwise, the PK value would not be wholly non-null or wholly null for
some security level. The third requirement states that the security level of values for the attributes
not in PK must dominate the security level of the PK attributes; otherwise, there could be instances
where non-null attributes would be associated with a null primary key when viewed below the level
of the primary key. These three requirements can be more formally defined as follows:

A multilevel relation schema R is said to satisfy entity integrity, if for all relation instances Rc
of R and, tuple t ¿ Rc,

1. If Ai ¿ PK, then t[Ai] ùnull,

2. If Ai, Aj ¿ PX, then t[Ci] = t[Cj], i.e., PK is said to be uniformly classified, and

3. If Ai ¿ PK, then t[Ci] t[C[PK]] (where C[PK] is the classification of the apparent
primary key PK).

3.5 REFERENTIAL INTEGRITY IN MULTILEVEL RELATIONS

As discussed in the previous section, a non-null foreign key value in a referencing relation should
always have a matching primary key value in the referenced relation. In an MLS database, this
requirement has implications for the relationship among the security levels of the attributes of the
foreign key and the security level of the referenced primary key. In addition, the possible actions
which could be taken to enforce referential integrity on update and deletion can introduce covert
channels as discussed in Section 4. Relation schemas, in the following example, will be used to
illustrate the different situations in which a security conflict may occur.

Example 5. Consider the multilevel relation schema PS given in Example 2. Person_Name is the
apparent primary key of the relation schema PS, and Starship is the foreign key of PS, which refers
to the relation schema SOD. Typical relation instances for SOD and PS are given in Figure 3.2.
Note that in the example schema only the attribute names are part of the primary key and the
foreign key. The respective security levels are not a part of the key. Therefore, there are some
tuples with the security level of the foreign key in relation PS higher or lower than the security level
of the corresponding primary key in relation SOD. The example includes such tuples to explain the
conflicts arising when the security levels are at different levels.

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration U

Talos U

Voyager U

Spying S

Mars S

Apollo S

Spying S

Moon S

PS

PERSON_NAME

STARSHIP

James Kirk U

Enterprise U

Mr. Spock U

Voyager S

Tim McKelley U

Apollo U

Figure 3.2: Typical Relation Instances for SOD and PS

Recall the definition of referential integrity for standard relational databases:

Referential Integrity: If FK is a foreign key of R1 referencing R2, PK is the primary key of
R2, t1 is a tuple of an instance R1 of R1, and t2 is a tuple of an instance R2 of R2, then

1. t1 [FK] is either wholly null or wholly non-null, and

2. Whenever t1[FK] is non-null, there is a tuple t2 in R2 such that t1[FK] = t2[PK].

For MLS databases we need to have this property be true for the database as seen from any security
level. Assume tl [FK] is not wholly null as viewed from some security level. The first requirement
above says that it must then be wholly non-null. If the attribute values making up FK did not all
have the same security level, there would be some security level for which some of the attribute
values in FK would be null and others non-null. Since this is not allowed, all attribute values in FK
must have the same security level. If all attribute values of FK are null, then by convention they
are assigned the same security level. This argument gives us the first rule for referential integrity.

Rule 1. The foreign key of the referencing relation must be uniformly classified (i.e., all
attribute values that make up the foreign key must be assigned an identical security level).

This rule is automatically satisfied for tuple level labeling.

The second part of referential integrity requires that if the foreign key FK is not null then there is
a matching primary key PK in the referenced relation R2. For this to be true for the database as
seen from the security level of FK, the matching PK must be visible at the security level of FK.
Hence, the security level of FK must dominate the security level of the matching primary key PK.
This gives us the second rule of referential integrity.

Rule 2. The security level of the foreign key must dominate the security level of the primary
key of the referenced tuple (i.e., C[FK] > C[PK]).

For tuple level labeling, this rule reduces to the requirement that the security level of the referenced
tuple must be dominated by the security level of the referencing tuple.

PS

PERSON_NAME

STARSHIP

James Kirk U

Enterprise U

Mr. Spock U

Null U

Tim McKelley U

Apollo U

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration U

Talos U

Voyager U

Null U

Null U

Figure 3.3: Unclassified Instances of PS and SOD Relations

Example 6. Consider the relations SOD and PS as shown in Figure 3.2. An Unclassified user sees
the two relations as given in Figure 3.3. For the Unclassified user, the referential integrity property
has been violated because there is no Starship “Apollo” visible to the Unclassified user. From the
Unclassified user’s point of view either Starship “Apollo” does not exist, which is a referential
integrity error, or it references a classified Starship that is not displayed to the user, which is a
security error.

3.6 ENFORCEMENT OF INTEGRITY CONSTRAINTS

Most of the research work on the topics covered in this document has either focused on
polyinstantiation as a mechanism to deal with primary key requirements and entity integrity or has
dealt with the broader question of inference. Meadows did some early work on the conflicts of
integrity and security that mainly considered approaches for maximizing integrity while
eliminating inference channels [Meadows 88]. Polyinstantiation and inference research are
covered in the appropriate TDI companion documents. However, there are several works dealing
with aspects of database integrity which go beyond just entity and referential integrity and do not
fit into those areas.

Notargiacomo and Wiseman have explored separation of duty as an approach to protect data from
unauthorized modification within MLS databases [Notargiacomo 91; Wiseman 90]. The concept
of applying separation of duty to integrity enforcement is to ensure that, before a modification to
the state is made, sufficient people agree that it properly reflects the real world requirement. The
fact that certain users are unlikely to collude with a particular change, an underlying assumption,
is indicated by the way roles are assigned to users. Notargiacomo explores the issues of integrating
an interpretation of the Clark-Wilson integrity model [Clark 87, 88] into a multilevel DBMS
security policy. Her preliminary investigation raised issues on object granularity; interaction of
MAC, DAC, and integrity policies; application of Clark-Wilson type controls to classes of users;
and the need for nested transactions. Wiseman sees the high level abstract view of separation of
duty as several people agreeing to change state. Integrity can be encouraged by enforcing
constraints which ensure the state is always valid and by subjecting inputs to separation of duty.

Reind van de Reit and Beukering describe how constraints involving integrity and security can be
specified in MOXUM, their active object-oriented knowledge-base system [van de Reit 94]. Their
premise is that changes to the database should be governed by rules in the form of integrity
constraints and security checks. In this case, integrity constraints refer to the quality of the data,
while security constraints refer to protection and access rights. Both kinds of constraints are
specified in MOKUM as Prolog predicates and are not separated. Each time some manipulation on
an object or a collection mentioned in a constraint is performed (create/change/inspect/destroy),
some check has to be performed. The Prolog scripts regulate access to object collections and
enforce integrity constraints through triggers. This implies a need to extend the Trusted Computing
Base to include the Prolog compiler which is problematic with respect to assurance.

In addition to considering the entity and referential integrity conflicts with security, Maimone and
Allen provide alternatives to resolving problems that arise in maintaining transaction integrity and
value constraints [Maimone 91]. A security conflict with transaction integrity may arise if a single
transaction is designed so that some steps must perform write operations at different security
levels. Value constraints are defined integrity rules that may restrict the valid values for a data
element. A conflict arises when some existing data classified above the label of the user activating
the constraint does not meet constraints defined after object creation. They make the distinction
between the use of triggers and constraints for enforcing integrity rules. The utility of declarative
constraints, including primary and foreign key and value or domain constraints, is that the
constraint declares an invariant property, detailing the meaning of a consistent state.

Marks and Jajodia [Jajodia 94] have developed a technique to enforce certain integrity constraints
and minimize the amount of sensitive information disclosed. They transform multilevel constraints
into constraints that can be enforced at individual levels and approximate enforcement of the
multilevel constraint.

SECTION 4

COVERT CHANNELS

The B2 or higher MAC requirements of the TCSEC specify that an MLS system must additionally
guard against indirect accesses through information flows. It is recognized that some covert
channels will exist in any system. The TCSEC provides guidelines on what actions must be taken
for channels depending on the bandwidth of the channel. Enforcement of integrity constraints can
create covert channels. These channels are discussed in this section. Interpretations indicating
precisely what channels will be deemed acceptable for systems evaluated against various TCSEC
levels will be developed as the Evaluation Community deals with specific vendor implementations.

4.1 PRIMARY KEY UNIQUENESS

Problems arise in multilevel relations when a user at a lower security level tries to enter a tuple with
the same primary key value as that of an existing tuple at a higher security level or when a user
tries to update the primary key attribute to a value that already exists at a higher level. This insert/
update cannot be allowed if primary key uniqueness is to be preserved. On the other hand, if the
user is not allowed to insert the primary key value, then there exists a covert channel. The following
example provides a concrete illustration.

Example 7. Consider the multilevel relation schema SOD of Example 4 in Section 3.2; the actual
relation is the same as the Secret instance shown in Figure 3.3. Suppose the Unclassified user, who
sees the Unclassified instance in Figure 3.3, attempts to update the missing values in the second
tuple corresponding to the starship “Voyager.” If the user is allowed to do this update, then there
will be two tuples corresponding to the primary key value of Starship “Voyager” in the Secret
instance, leading to a violation of the primary key constraint, as shown in Figure 4.1. But if the
Unclassified user’s attempt is rejected, then there is a channel. Since this is unacceptable, a way
must be found to deal with the existence of both tuples in the Secret instance.

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration U

Talos U

Voyager U

Spying S

Mars S

Voyager U

Exploration U

Moon U

Figure 4.1: SOD After Insertion of Tuple Corresponding to Starship = “Voyager” by
Unclassified User

Since the user can infer that a Secret tuple exists with the same primary key the user is attempting
to insert, this channel can be viewed as an example of inference. However, it also represents a
covert channel because a Secret process can insert or delete tuples with a given primary key and
this action could be detected by the Unclassified user. To avoid this channel, both the Secret tuple
and the Unclassified tuple for the starship “Voyager” must somehow co-exist in the instance at the
Secret level.

These security considerations have led to the notion of polyinstantiation [Denning 87].
Polyinstantiation forces a relation to contain multiple tuples with the same primary key but
distinguishable by their classification levels or by the non-primary key attributes of the relation
[Lunt 91]. It is because the user designated primary key must be augmented with classification
levels to maintain primary key uniqueness in a polyinstantiated database that we have used
Denning” term apparent primary key for the user-specified primary key. Jajodia contends that the
use of polyinstantiation for cover stories needs to be confined to those cases where it is intended
since uncontrolled use of polyinstantiation leads to further loss of integrity and confusion with the
semantics of the relational data model [Jajodia 90].

The debate continues as to whether polyinstantiation is needed in multilevel relations or not
[Sandhu 91]. If polyinstantiation is not required in multilevel relations, then there must be a
solution to close channels. If polyinstantiation is used, then the question is how polyinstantiation
should be managed. Burns maintains that as a result of the fundamental conflict with enforcing
confidentiality and secrecy of information in an MLS database with integrity, DBMS products will
have to be expanded to include the ability to correct the errors and inconsistencies introduced by
polyinstantiation [Burns 90a]. A thorough discussion of all the issues associated with
polyinstantiation is beyond the scope of this document, but is covered in another volume in this
series: Polyinstantiation Issues in Multilevel Secure Database Management Systems [Poly 96]. For
the purpose of this document, the discussion of polyinstantiation is confined to the impact it has on
referential integrity.

4.2 ENFORCEMENT OF REFERENTIAL INTEGRITY RULES

Section 3 showed that for referential integrity in an MLS database, the security level of the foreign
key must dominate the security level of the primary key of the referenced tuple (C [FK] C[PX]).
This requirement guarantees that the referenced primary key will be visible to any user who sees
the foreign key as non-null. However, the situation is somewhat more complicated if the referenced
relation is polyinstantiated. In this event, there may be more than one tuple with an apparent
primary key matching FK. Some method must be used to uniquely and consistently determine
which primary key will be considered to be the referenced primary key. One approach is to
augment FK with the security level of its attributes (the tuple security level if tuple level labeling
is used). If that approach is used, a matching PK will have the same security level as FX and the
requirement on the relationship between security levels of PK and FK becomes C[FK] = C[PK].

Enforcement of referential integrity through the rules described in Section 2.2 can result in covert
channels. These channels are discussed below. The discussion is divided into the two permitted
cases: C[FK] = C[PK] and C[FK] > C[PK].

4.2.1 Enforcement of Integrity Rules When C[FK] = C[PK]

To study the enforcement of integrity rules when the security level of the referencing tuple and the
security level of the referenced tuple are the same, we need to look at the cases of the four different
levels of granularity in multilevel relations. For relations with relation level labeling or tuple level
labeling, all the integrity rules are usable without modification because this case can be considered
to be equivalent to relationships occurring in a single-level database. For attribute and element
level labeling there is a potential channel for the CASCADFS-delete rule. All other rules can be
enforced without any problem. This channel can be better explained with the help of an example.

Example 8. Consider the two relations SOD and PS as given in Figure 4.2. The security level of
the foreign key in relation PS in this example is the same as the security level of the referenced
primary key in relation SOD. For the second tuple in relation PS, an Unclassified user oily sees the
attribute Person_Name. The user is not cleared to see the value of Starship for this tuple and also
the user cannot see the corresponding referenced tuple in relation SOD. Suppose a Confidential
user comes in and attempts to delete the second tuple in relation SOD where Starship = “Saratoga.”
If the delete rule specified is a CASCADES-delete, then the referencing tuple in PS is also deleted.
An Unclassified user now will not see the attribute value Person_Name = “Mr. Spock” any more,
and this causes a channel.

PS

PERSON_NAME

STARSHIP

James Kirk U

Enterprise U

Mr. Spock U

Saratoga C

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration C

Talos C

Saratoga C

Mining C

Rigel C

Figure 4.2: Relation PS and SOD when C[FK] = C[PK]

The channel in this case can be avoided if the equivalence of the security levels of the foreign key
and the referenced primary key is extended. If the security level of the entire referencing tuple is
the same as the security level of the entire referenced tuple, then no violations occur when
enforcing the insert, delete, and update rules. This fact has been acknowledged in the SeaView
model [Lunt 90] and the referential secrecy model given by Burns [Burns 90b]. Burns also suggests
selective enforcement of referential integrity in those cases where the security level of both the
referencing relation and the referenced relation are not the same, assuming that the channel either
can be monitored or is deemed not to cause a serious threat.

4.2.2 Enforcement of Integrity Rules When C[FK] > C[PK]

Now the final case will be considered where the security level of the referencing tuple dominates
the security level of the referenced tuple. Each of the integrity rules for insert, delete, and update
will be considered individually, and the effect of the dominance of the referencing tuple’s security
level over that of the referenced tuple will be investigated. The effect of different levels of labeling
granularity in multilevel relations upon enforcement of integrity will also be considered.
Throughout this discussion, we will assume that either the relations are not polyinstantiated or a
consistent method is employed to determine the unique primary key referred to by a foreign key.

1. Element-Level Granularity – Each of the integrity rules for insert, delete, and update is
examined individually for relations with element-level granularity, and conditions
violating the security constraints are investigated.

a. Delete Rule – As discussed in Section 2.2.1, the four delete rules for referential
integrity in single-level relations are as follows:

i. RESTRICTED-delete Rule

ii. CASCADES-delete Rule

iii. NULLIFIES-delete Rule

iv. SET-DEFAULT-delete Rule

Each of these rules is considered in turn for applicability to multilevel relations labeled at the
element level.

i. RESTRICTED-delete Rule – The RESTRICTED-delete rule states that the referenced
primary key tuple cannot be deleted as long as there is a corresponding referencing
tuple somewhere in the database. For instance, consider the relations SOD and PS
given in Figure 4.3.

In relation PS, the security level of the foreign key value Starship = “Voyager” dominates
the security level of the primary key value in the relation SOD. According to the
RESTRICTED-delete rule, as long as there is a tuple having foreign key value “Voyager”
in PS, the tuple with primary key value “Voyager” cannot be deleted from the relation
SOD. This gives rise to a channel, as there is a downward flow of information from the
high-level referencing foreign key to the low-level subject attempting to delete the tuple
containing the primary key. Therefore, the RESTRICTED-delete Rule violates secrecy
when the security level of the foreign key dominates the security level of the primary key
of the referenced tuple.

ii. CASCADES-delete Rule – If the delete rule specified is the CASCADES-delete rule,
then if the tuple in SOD with Starship = “Voyager” is deleted at the Unclassified level,
then the tuple in PS with Starship = “Voyager” at the Secret level should also be
deleted. In the relation instance of PS, given in Figure 4.3, Person_Name = “Mr.
Spock” is at the Unclassified level in the tuple containing Starship = “Voyager” at the
Secret level. Although the Unclassified user would not see any value for Starship in
the PS tuple with Person_Name = “Mr. Spock,” this tuple will be deleted as a result of
the CASCADES-delete action. Therefore, the user will be able to infer that the tuple
contained Starship = “Voyager.” This is a channel. If the attribute value “Mr. Spock”
were classified as Secret, there would have been no channel. Hence, the CASCADES-
delete rule fails in relations with element-level labeling and C[FK] > C[PK], if any
non-foreign key attribute value in the referencing tuple is at a lower security level than
the foreign key attribute value. Even though the CASCADES-delete rule is not invalid
for all the cases, channels exist that cannot be covered or be removed. Hence,
CASCADES-delete cannot be used for defining an integrity constraint in relations
with element-level labeling which allow a foreign key to strictly dominate its
corresponding primary key.

SOD

STARSHIP

OBJECTIVE

DESTINATION

Enterprise U

Exploration U

Talos U

Voyager U

Spying S

Mars S

Apollo S

Spying S

Moon S

PS

PERSON_NAME

STARSHIP

James Kirk U

Enterprise U

Mr. Spock U

Voyager S

Figure 4.3: Relations SOD and PS without Polyinstantiation

iii. NULLIFIES-delete Rule – If the delete rule specified is NULLIFIES-delete, then
the value of Starship = “Voyager” in relation PS is set to null when the tuple in SOD
for Starship = “Voyager” is deleted. This does not conflict with the security
constraints, as long as write-ups are allowed, since there would not be a downward
flow of information.

iv. SET DEFAULT-delete Rule – The argument for the SET DEFAULT-delete rule is
the same as for the NULLIFIES-delete rule. As previously noted, the SET
DEFAULT rule is equivalent to the NULLIFIES rule when null is specified as the
default.

In summary, when the foreign key value is higher than the security level of the primary key
value, then the NULLIFIES-delete rule and the SET DEFAULT-delete do not create
downward information flows. However, the RESTRICTED-delete and CASCADES-
delete rules can result in covert channels.

b. UPDATE Rule – As discussed in Section 2.2.2, the four update rules for referential
integrity in single-level relations are as follows:

i. RESTRICTED-update Rule

ii. CASCADES-update Rule

iii. NULLIFIES-update Rule

iv. SET DEFAULT-update Rule

The following paragraphs discuss the application of the update rules to multilevel relations labeled
at the element level.

i. RESTRICTED-update Rule – Consider the relations SOD and PS given in Figure
4.2. In relation PS, the security level of the foreign key value Starship = “Voyager”
dominates that of the primary key value in the relation SOD. According to the
RESTRICTED-update rule, as long as there is a tuple having foreign key value
“Voyager” in PS, the primary key value “Voyager” cannot be updated in the
relation SOD. This gives rise to a channel because there is flow of information from
the high-level referencing foreign key to the low-level subject attempting to delete
the tuple containing the primary key. Therefore, the RESTRICTED-update Rule
will not work when updating a referenced tuple if the security level of the
referencing tuple dominates the security level of the referenced tuple.

ii. CASCADES-update Rule – The CASCADES-update Rule states that if the primary
key value Starship = “Voyager” in SOD is updated, then the foreign key value
Starship = “Voyager” in PS will also be updated. This does not conflict with the
security constraints, as long as write-ups are allowed, since there would not be a
downward flow of information.

iii. NULLIFIES-update Rule – The NULLIFIES-update Rule specifies that the value of
Starship = “Voyager” in relation PS be set to null if Starship = “Voyager” in SOD
is updated. Again, this does not conflict with the security constraints, as long as
write-ups are allowed, since there would not be a downward flow of information.

iv. SET DEFAULT-update Rule – The SET DEFAULT-update Rule does not violate
any security or integrity constraints when the security level of the foreign key
dominates the security level of the primary key. The explanation is the same as for
the NULLIFIES-update rule.

In summary, CASCADES-update, NULLIFIES-update, and SET DEFAULT-update do
not result in downward information flow. The RESTRICTED-update rule can result in a
covert channel.

c. INSERT Rule – The insert rule for integrity states that the insertion of a foreign key
value should comply with the referential integrity rules; that is, each foreign key value
in the referencing relation should have an identical primary key value in the referenced
relation. In MLS databases, it is important to ensure that there is no downward flow of
information when the insertion is made. If the security level of the referencing tuple
(foreign key value) dominates the security level of the referenced tuple (primary key
value), then there is no such possibility of a channel. If a higher user attempts to insert
a foreign key value, the user’s insertion is accepted or rejected based on the presence
or absence of the referenced value at the lower security level. There will be only an
upward flow of information, which means that both integrity and security rules are
satisfied. It should be noted that, unlike with polyinstantiated relations, there is no
confusion while inserting the tuples in the two relations.

SOD

No.

STARSHIP

OBJECTIVE

DESTINATION

TC

1

Enterprise

Exploration

Talos

U

2

Enterprise

Spying

Mars

S

PS

No.

PERSON_NAME

STARSHIP

TC

3

James Kirk

Enterprise

U

4

Mr. Spock

Enterprise

S

Figure 4.4: Relations with Tuple-Level Granularity

2. Tuple-Level Granularity – The argument for referential integrity control in relations with
tuple-level granularity is the same as the discussion above for element-level granularity. The only
difference is that instead of each data element having an individual security level, the entire tuple
in the relation is assigned a security level as shown in Figure 4.4. As is the case for element-level
granularity, a security conflict occurs when the RESTRICTED-update/delete option is enforced.
There is a downward flow of information when a low user tries to update/delete a target value, and
is allowed to do so depending on the absence of a matching referencing tuple at a higher level. All
other integrity rules are valid for relations with tuple-level granularity. The problem with
CASCADES-delete that occurs for element-level granularity does not occur with tuple-level
granularity because, for tuple-level granularity, each element in the tuple is explicitly assumed to
have the same security level as defined in the tuple class. As such, a user will never be in the
situation where he can view some attributes of a tuple but not others and then witness the tuple
vanish due to a cascading delete on attributes that the user is not cleared to see, which would be a
covert channel due to the inference of the high attribute’s value.

3. Attribute-Level Granularity – As described earlier, attribute-level granularity means that each
attribute in a relation is assigned a single security level. All values of an attribute are classified at
the same level of security across all tuples in the relation. From the discussion in Section 3.5, to
maintain referential integrity, the security level of the foreign key attribute in the referencing
relation must dominate the security level of the primary key attribute in the referenced relation.

The case to be considered is where the security level of the foreign key attribute strictly dominates
the security level of the apparent primary key attribute. In this case, the relations SOD and PS are
as given in Figure 4.5.

SOD

No.

STARSHIP U

OBJECTIVE S

DESTINATION U

1

Enterprise

Exploration

Talos

2

Voyager

Spying

Mars

PS

No.

PERSON_NAME U

STARSHIP S

3

James Kirk

Enterprise

4

Mr. Spock

Enterprise

Figure 4.5: Relations with Attribute-Level Granularity

Following the discussion earlier, it can be observed that all the integrity rules can be applied to the
case above except for the RESTRICTED-delete or the RESTRICTED-update rule. Under
RESTRICTED-update or delete, whenever a lower subject tries to update or delete the tuple
containing a particular primary key attribute value, the attempt is accepted or rejected based on the
presence of a matching value in the foreign key attribute at the higher security level. This gives rise
to a channel.

4. Relation-Level Granularity – As defined earlier, a relation with relation-level granularity has
a single classification level defined for the entire relation, or in other words, all data elements in
the relation are at the same security level.

For instance, consider the relation schema SOD, given in Example 4, and the relation
schema PS, given in Example 6. Relation PS references relation SOD, with Starship being
the foreign key attribute. The security level of the primary key “Starship” (i.e., C[PK]) is
the same as the security level of the relation SOD, and the security level of the foreign key
“Starship” (i.e., C[FK]) is the same as the security level of the relation PS. Based on the
restrictions derived in rule 2 in Section 3.5, the security level of the foreign key should
always dominate the security level of the primary key. Therefore, for relation-level
granularity, the security level of the relation PS should dominate the security level of the
relation SOD.

Let the security level of relation SOD be Unclassified and of PS be Secret. Then C[FK] =
Secret and C[PK] = Unclassified (i.e., C[FK] > C[PK]). From the discussion in Section 3.5,
it can be seen that, if C[FK] > C[PK], then all integrity rules except RESTRICTED-delete
and RESTRICTED-update can be used, without any covert channels.

The table below gives a summary of the integrity rules that apply to different levels of granularity
without compromising secrecy by permitting downward information flows. In the case of
polyinstantiated relations it is necessary in all cases that there be a method to unambiguously
determine which instance of the apparent key is referenced.

Level of Granularity

Element

Tuple

Attribute

Relation

Insert Rule

OK

OK

OK

OK

Delete Rules:

RESTRICTED-delete

Channel

Channel

Channel

Channel

CASCADES-delete

Channel

OK

OK

OK

NULLIFIES-delete

OK

OK

OK

OK

SET-DEFAULT-
delete

OK

OK

OK

OK

Update Rules:

RESTRICTED-update

Channel

Channel

Channel

Channel

CASCADES-update

OK

OK

OK

OK

NULLIFIES-update

OK

OK

OK

OK

SET-DEFAULT-
update

OK

OK

OK

OK

Table 4.1: Summary of Covert Channels in Referential Integrity Rules for C[FK] > C[PK]

4.3 RELATION TO DBMS ARCHITECTURE

A Trusted Computing Base (TCB) consists of one or more sub-elements that together enforce a
security policy over a system. Complex systems distribute policy enforcement to various sub-
elements. While determining the trust characteristics of a complex system on the basis of a
collection of subparts is not well understood, there are approaches for arguing about composition
of systems.

The approach used in the TDI is to view the system as being composed of hierarchically-ordered
systems. There is a “privilege” hierarchy characterized by dependency. The construct developed
for dealing with layered systems is TCB subsets. A TCB subset enforces a security policy over a
set of resources for that layer, and may or may not include hardware. If a TCB subset can be shown
to be constrained and unprivileged relative to the more primitive TCB subset from which it obtains
resources, then the scope of the covert channel analysis can be limited. An example of this
approach is the SeaView prototype.

SRI International developed the SeaView prototype multilevel RDBMS to validate the SeaView
theoretical model and to demonstrate that the prototype is suitable for engineering development
[Hsieh 93]. The design approach provides users with element-level labeling. SeaView constructs
multilevel relations as views over stored single-level relations. The single-level relations are stored
in files managed by an underlying multilevel operating system. Thus, individually labeled data
elements need not be stored in individually labeled storage objects. The SeaView approach allows
multilevel database operations to be decomposed into corresponding single-level operations on the
single-level relations. The decomposition is transparent to the user, who considers the multilevel
relations to be stored relations. Thus, the SeaView model extends entity and referential integrity to
multilevel relations. It also allows application dependent integrity rules to be defined on multilevel
relations; and it ensures that updates of multilevel relations are well defined. In addition, the
SeaView model constrains multilevel relations with polyinstantiation integrity, which specifies
consistency for polyinstantiated tuples and elements.

In the SeaView approach, the underlying architecture guards against covert channels during
enforcement of entity and referential integrity. This is because the DBMS instance operating on
behalf of a subject is untrusted with respect to the underlying operating system MAC policy (i.e.,
it can only read data with a security level dominated by the subject’s level and can only write data
with a security level dominating the subject’s level). SRI utilized Trusted Oracle OS MAC Mode,
which has been evaluated as a constrained TCB subset architecture [Oracle 94].

On the other hand, a secure DBMS can be built with MAC enforcement done in the DBMS, not
just the underlying operating system. In this approach, the DBMS will have the privilege to violate
the operating system’s MAC controls. With this architecture, called a trusted subject architecture,
the DBMS designer has to make a tradeoff between channel free enforcement of entity and
referential integrity constraints, or enforcement of the constraints in a manner which allows
selected channels. In the latter case, the constraint enforcement mechanism must be carefully
analyzed to make sure that the downward information flows are thoroughly understood and that
they are acceptable for the target environment or evaluation class. For example, Trusted Oracle7
DBMS MAC Mode (which uses the trusted subject architecture) was successfully evaluated at
Class B1 [Oracle 94]. In DBMS MAC Mode, entity and referential integrity can be enforced. An
audit event was added to Trusted Oracle7 to detect use of potential covert channels.

SECTION 5

SUMMARY

Entity integrity and referential integrity are two important integrity constraints that should be
enforced by the DBMS. While entity integrity is necessary for preserving correctness of data
within a relation, referential integrity is required for maintaining interrelation integrity in the
relational data model. In this document, these concepts have been extended to multilevel DBMSs.

The extension of the concept of referential integrity from single-level relations to multilevel
relations is not straightforward. This is because restrictions are needed to provide referential
integrity control in multilevel DBMSs without compromising secrecy. The basic requirement for
referential integrity is that each referencing foreign key value must have an identical target primary
key value in the referenced relation. An additional requirement for multilevel relations is that each
foreign key and primary key should be uniformly classified (i.e., all attributes included in a key
should have the same security level) and each foreign key dominates its referenced primary key.

From the discussion in the document, it can be concluded that enforcing referential integrity, when
the security level of the foreign key is equal to the security level of the referenced primary key, is
simple and without any ambiguity. All integrity rules apply in this case, whether the relations allow
polyinstantiation or not. When polyinstantiation is allowed, some method such as including the
security level of the primary and foreign key values as part of the key must be used to differentiate
references, and allow the referential integrity rules to be enforced.

Referential integrity completely fails when the security level of the foreign key does not dominate
the security level of the primary key. When the security level of the foreign key strictly dominates
the security level of the referenced primary key, some of the integrity rules for actions to be taken
upon deletion or modification of a key value can be applied without channels, with some
differences based on labeling granularity.

Inclusion of a mechanism which enforces integrity across security levels in Class B2 and above
DBMSs may not be feasible due to conflicts with the covert channel requirements. However, with
the successful evaluation of Trusted Oracle7 DBMS MAC Mode with an unmodified integrity
mechanism, precedence has been set for Class B1 DBMSs.

REFERENCES

[ANSI 92] ANSI. Database Language SQL2. In ANSI X3.135-1992, American National
Standards Institute, New York. December 1992.

[ANSI 94] ANSI. SQL3 – Working Draft. Draft Version, Available From X3 Secretariat,
Computer and Business Equipment Manufacturers Association (CBEMA), 1250
Eye St. N.W., Suite 200 Washington, D.C. 20005-3992. September 1994.

[Audit 96] National Computer Security Center, Auditing Issues in Secure Database
Management Systems, NCSC Technical Report-005, Volume 4/5, May 1996.

[Bell 76] D. E. Bell and L. J. LaPadula. Secure Computer Systems: Unified Exposition and
Multics Interpretation, The MITRE Corporation. March 1976.

[Burns 90a] R. K. Burns. Integrity and Secrecy: Fundamental Conflicts in the Database
Environment. In Proceedings of the Third RADC Database Security Workshop,
Castille, NY. 1990.

[Burns 90b] R. K. Burns. Referential Secrecy. In Proceedings of the IEEE Symposium on
Security and Privacy, IEEE Computer Society Press. May 1990.

[Clark 87] D. D. Clark and D. R. Wilson. A Comparison of Commercial and Military
Computer Security Policies. In Proceedings of the IEEE Symposium on Security
and Privacy, Oakland, CA. May 1987.

[Clark 88] D. D. Clark and D. R. Wilson. Evolution of a Model for Computer Integrity. In
Proceedings of the 11th National Computer Security Conference, Baltimore,
MD. October 1988.

[DAC 96] National Computer Security Center, Discretionary Access Control Issues in
High Assurance Secure Database Management Systems, NCSC Technical
Report-005, Volume 5/5, May 1996.

[Date 86] C. J. Date. An Introduction to Database Systems, Vol. I, 4th Edition, Addison-
Wesley, Reading, MA. 1986.

[Date 90] C. J. Date. Referential Integrity and Foreign Keys: Further Considerations. In
Relational Database Writings 1985-1989, Addison-Wesley, pp. 99-184. 1990.

[Denning 87] D. E. Denning, T. F. Lunt, R. R. Schell, M. Heckman, and W. R. Shockley. “A
Multilevel Relational Data Model,” Proceedings of the 1987 IEEE Symposium
on Security and Privacy, IEEE Computer Society Press, pp. 220-234. 1987.

[DoD 85] Department of Defense Trusted Computer System Evaluation Criteria, DoD
5200.28-STD, Washington, DC. December 1985.

[Hsieh 93] D. Hsieh, T. Lunt, and P. Boucher. The SeaView Prototype. RL-TR-93-216 Final
Technical Report, SRI International. November 1993.

[Horowitz 92] B. M. Horowitz. A Run-Time Execution Model for Referential Integrity
Maintenance. In Proceedings of the 8th International Conference on Data
Engineering, Tempe, AZ, pp. 548-556. February 1992.

[Inference 96] National Computer Security Center, Inference and Aggregation Issues in Secure
Database Management Systems, NCSC Technical Report-005, Volume 1/5,
May 1996.

[Jajodia 90] S. Jajodia, and R. Sandhu. Polyinstantiation Integrity in Multilevel Relations. In
Proceedings of the 1990 IEEE Symposium on Security and Privacy, Oakland,
CA. May 1990.

[Jajodia 91] S. Jajodia, and R. Sandhu. Toward a Multilevel Secure Relational Data Model.
In Proceedings of ACM SIGMOD International Conference on Management of
Data, Denver, CO, pp. 50-59. May 1991.

[Jajodia 94] S. Jajodia and D. G. Marks. Maintaining Secrecy and Integrity in Multilevel
Databases: A Practical Approach. In Proceedings of the 18th National
Information Systems Security Conference, Baltimore, MD. Oct. 10-13 1995.

[Khoshafian 86] S. N. Khoshafian and G. P. Copeland. Object Identity. In Proceedings for
OOPSLA 1986. pp. 406-416. September 1986.

[Lunt 90] T. F. Lunt, D. E. Denning, R. R. Schell, M. Heckman, and W. R. Shockley. The
SeaView Security Model. In IEEE Transactions on Software Engineering, Vol.
16, No. 6, pp. 593-607. June 1990.

[Lunt 91] T. F. Lunt, and D. Hsieh. Update Semantics for a Multilevel Relational Database
System. In Database Security, IV: Status and Prospects, S. Jajodia and C. E.
Landwehr (editors), Elsevier Science Publishers B. V. (North Holland), IFIP, pp.
281-296.1991.

[Maimone 91] B. Maimone and R. Allen. Methods for Resolving the Security vs. Integrity
Conflict. In Research Directions in Database Security, IV: Proceedings of the
Fourth RADC Workshop, Rae Burns (editor). April 1991.

[Markowitz 90] V. M. Markowitz. Referential Integrity in Relational Database Management
Systems: A Comparative Study. Preprint. 1990.

[Meadows 88] C. Meadows and S. Jajodia. Integrity Versus Security in Multi-Level Secure
Databases. In Database Security Status and Prospects, ed. C. Landwehr, North
Holland. 1988.

[Notargiacomo 91] L. Notargiacomo. Database Integrity: Based on the Clark-Wilson Integrity
Model. In Proceedings of the 3rd RADC Database Security Workshop. 1991.

[Oracle 94] Oracle7 and Trusted Oracle7 Final Evaluation Report, NCSC-EPL-94/004, C-
Evaluation Report No. 07-95, Library No. S242,198, National Computer
Security Center, 5 April 1994.

[Poly 96] National Computer Security Center, Polyinstantiation Issues in Multilevel
Secure Database Management Systems, NCSC Technical Report-005, Volume
3/5, May 1996.

[Sandhu 91] R. Sandhu and S. Jajodia. Honest Databases That can Keep Secrets. In
Proceedings 14th National Computer Security Conference, Washington, D.C.
Oct. 1991.

[TDI 91] Trusted Database Management System Interpretation of the Trusted Computer
System Evaluation Criteria, NCSC-TG-021, National Computer Security
Center. April 1991.

[van de Reit 94] R. van de Reit and J. Beukering. The Integration of Security and Integrity
Constraints in MOKUM. In Proceedings of the 8th IFIP 11.3 WG on Database
Security. Bad Sdzdetfurth, Germany, 23-26 August 1994.

[Wiseman 90] S. Wiseman. The Control of Integrity in Databases. In Proceedings of the 4th
IFIP 11.3 WG on Database Security, Halifax, England, 18-21 September 1990.
Rank
Person_Name
Primary key
PR
Foreign key
Primary key
Starship
Person_Name
Foreign key
PS
Primary key
Starship
Objective
Destination
SOD
Keith F. Brewster

Acting Chief, Partnerships and Processes
May 1996

Modem Noise Destroyer (Alpha Version)

Modem Noise Killer (alpha version)

With this circuit diagram, some basic tools including a soldering iron, and
four or five components from Radio Shack, you should be able to cut the
noise/garbage that appears on your computer’s screen.

I started this project out of frustration at using a US Robotics 2400 baud
modem and getting a fare amount of junk when connecting at that speed. Knowing
that capacitors make good noise filters, I threw this together.

This is very easy to build, however conditions may be different due to modem
type, amount of line noise, old or new switching equipment (Bell’s equipment),
and on and on. So it may not work as well for you in every case. If it does
work, or if you’ve managed to tweek it to your computer/modem setup I’ d like
to hear from you.

I’d also appreciate any of you electronic wizzards out there wanting to offer
any improvements. Let’s make this work for everyone!

Please read this entire message and see if you understand it before you begin.

OK, what you’ ll need from Radio Shack:

1 #279-374 Modular line cord if you don’t already have one. You won’t need one
if your phone has a modular plug in its base. $4.95

1 #279-420 Modular surface mount jack (4 or 6 conductor) $4.49

1 #271-1720 Potentiometer. This is a 5k audio taper variable resistor. $1.09

1 #272-1055 Capacitor. Any non-polarized 1.0 to 1.5 uf cap should do. Paper,
Mylar, or metal film caps should be used, although #272-996 may work as well.
(272-996 is a non-polarized electrolytic cap) $.79

1 100 ohm resistor – quarter or half watt. $.19

1 #279-357 Y-type or duplex modular connector. Don’t buy this until you’ve read
the section on connecting the Noise Killer below. (A, B,or C) $4.95

First off, open the modular block. You normally just pry them open with a
screwdriver. Inside you’ll find up to 6 wires. Very carefully cut out all but
the green and red wires. The ones you’ll be removing should be black, yellow,
white, and blue. These wires won’t be needed and may be in the way. So cut them
as close to where they enter the plug as possible. The other end of these wires
have a spade lug connector that is screwed into the plastic. Unscrew and remove
that end of the wires as well. Now, you should have two wires left. Green and
red. Solder one end of the capacitor to the green wire. Solder the other end of
the capacitor to the center lug of the potentiometer (there are three lugs on
this critter). Solder one end of the resistor to the red wire. You may want to
shorten the leads of the resistor first. Solder the other end of the resistor
to either one of the remaining outside lugs of the potentiometer. Doesn’t
matter which. Now to wrap it up, make a hole in the lid of the mod block to
stick the shaft of the potentiometer through. Don’t make this hole dead center
as the other parts may not fit into the body of the mod block if you do. See
how things will fit in order to find where the hole will go. Well, now that
you’ve got it built you’ll need to test it. First twist the shaft on the
potentiometer until it stops. You won’t know which way to turn it until later.
It doesn’t matter which way now. You also need to determine where to plug the
Noise Killer onto the telephone line. It can be done by one of several ways:

A. If your modem has two modular plugs in back, connect the Noise Killer into
one of them using a line cord. (a line cord is a straight cord that connects a
phone to the wall outlet. Usually silver in color)

B. If your phone is modular, you can unplug the cord from the back of it after
you’re on-line and plug the cord into the Noise Killer.

C. You may have to buy a Y-type modular adaptor. Plug the adaptor into a wall
outlet, plug the modem into one side and the Noise Killer into the other. Call
a BBS that has known noise problems. After you’ve connected and garbage begins
to appear, plug the Noise Killer into the phone line as described above. If you
have turned the shaft on the potentiometer the wrong way you’ll find out now.
You may get a lot of garbage or even disconnected. If this happens, turn the
shaft the other way until it stops and try again. If you don’t notice much
difference when you plug the Noise Killer in, that may be a good sign. Type in
a few commands and look for garbage characters on the screen. If there still
is, turn the shaft slowly until most of it is gone. If nothing seems to happen
at all, turn the shaft slowly from one side to the other. You should get plenty
of garbage or disconnected at some point. If you don’t, reread this message to
make sure you’ve connected it right.

***END OF ORIGNAL FILE***

ADDITION TO ORIGNAL FILE – 2/29/88 – Mike McCauley – CIS 71505,1173

First, a personal recomendation. _THIS WORKS!!!_ I have been plagued with
noise at 2400 for some time. I went round and round with Ma Bell on it, and
after they sent out several “repair persons” who were, to be kind, of limited
help in the matter, I threw in the towel. I saw this file on a board up east
a few days ago, and thought I’d bite. Threw the gismo together in about 10
minutes, took another five to adjust the pot for best results on my worst
conection, and guess what? No more worst connecion! A few pointers:

1) The pot need not be either 5K or audio taper. I used a 10K 15 turn trim pot.
Suggest you use what is handy.
2) I used 2MFD’s of capacitance (two 1MFD’s in parallel) Two R.S. p/n 272-1055
work fine. Remember that about 90 Volts will appear across red & green at
ring, so the caps should be rated at 100VDC+.
3) I ended up with a final series resistance value (100 ohm + pot) of 2.75K.
I speculate that one could probably use 2MFD and a fixed 2.7K resistor and
do the job 90% of the time. The adjustment of the pot is not very critical.
Changes of +/- 1K made little difference in the performance of the circuit.

Hope it works as well for you as it did for me.

Mike McCauley


Hacking Techniques, Typed in by Logan5 from The Inner Circle

 
****************************
***  HACKING TECHNIQUES  ***
***  Typed By:  LOGAN-5  ***
***   (Hacker Supreme)   ***
***       From the       ***
***   Inner Circle Book  ***
****************************

1) CALLBACK UNITS:

Callback units are a good security device, But with most phone systems,
it is quite possible for the hacker to use the following steps to get
around a callback unit that uses the same phone line for both incomming 
and out going calls:First, he calls he callback unit and enters any 
authorized ID code (this is not hard to get,as you'll see in a moment).
After he enters this ID, the hacker holds the phone line open - he does 
not hang up. When the callback unit picks up the phone to call the user back,
the hacker is there, waiting to meet it.

 The ID code as I said, is simple for a hacker to obtain, because these 
codes are not meant to be security precautions.The callback unit itself 
provides security by keeping incomming calls from reaching the computer.
The ID codes are no more private than most telephone numbers. Some callback 
units refer to the codes as "location identification numbers," and some 
locations are used by several different people,so their IDs are fairly 
well known.I've been told that, in some cases,callback ubits also have 
certain simple codes that are always defined by default. Once the hacker 
has entered an ID code and the callback unit has picked up the phone to 
re-call him,the hacker may or may not decide to provide a dial tone to 
allow the unit to "think" it is calling the correct number. In any event,
the hacker will then turn on his computer, connect with the system - and 
away he goes.If the however, the hacker has trouble holding the line with 
method,he has an option: the intercept.

The Intercept: 
 Holding the line will only work with callback units that use the same 
phone lines to call in and to call out.Some callback units use different
incoming and outgoing lines, numbers 555-3820 through 555-3830 are dedicated 
to users' incoming calls, and lines 555-2020 through 555-2030 are dedicated 
to the computers outgoing calls.The only thing a hacker needs in order to 
get through to these systems is a computer and a little time - he doesn't 
even need an ID code. First,the hacker calls any one of the outgoing phone 
lines, which, of course, will not answer.Sooner or later, though, while the 
hacker has his computer waiting there, listening to the ring, an authorized 
user will call one of the incomming lines and request to be called back.
It will usually be less than an hours wait, but the hacker's computer 
is perfectly capable of waiting for days, if need be.

 The callback unit will take the code of the authorized user, hang up, 
verify the code, and pick up the phone line to call back.If the unit 
tries to call out on the line the hacker has dialed, the hacker has his 
computer play a tone that sounds just like a dial tone.The computer will 
then dial the number given that matches up with the user's authorized ID.
After that,the hacker can just connect his computer as he would in any 
other case.If he is really serious,he will even decode the touch tones 
that the mainframe dialed,figure out the phone number of the user the 
system was calling, call the person, and make a few strange noises that 
sound as though the computer called back but didnt work for some reason.

2) TRAPDOORS AS A POSSIBLILITY

 I haven't heard of this happening, but i think it is possible that a 
callback modem could have a trapdoor built into it.Callback modems are
run by software, which is written by programmers.An unscrupulous programmer 
could find it very easy to slip in an unpublicized routine, such as, 
"if code =*43*, then show all valid codes and phone numbers." And such a 
routine, of course, would leave security wide open to anyone who found the 
trapdoor.The obvious protection here, assuming the situation ever arises,
is simply an ethical manufactorer that checks its software thoroughly before 
releasing it.

 A trapdoor is a set of special instructions embedded in the large 
program that is the operating system of a computer.A permanent, 
hopefully secret "doorway", these special instructions enabe anyone who 
knows about them to bypass normal security procedures and to gain access to 
the computer's files.Although they may sound sinister, trapdoors were not 
invented by hackers, although existing ones are certainly used by hackers 
who find out about them.

3) THE DECOY

 One of the more sophisticated hacking tools is known as the decoy, and it 
comes in three versions.The first version requires that the hacker have an 
account on the system in question. As in my case,the hacker has a 
low-security account,and he tries this method to get higher-security 
account.He will first use his low-security account to write a program that 
will emulate the log-on procedures of the systems in questions. 
This program will do the following:

*- Clear the terminal screen and place text on it that makes everything 
look as if the system is in charge.

*- Prompt for, and allow the user to enter, both an account name and a password.
*- Save that information in a place the hacker can access.

*- Tell the use the account/password entries are not acceptable.

*- turn control of the terminal back over to the system.

The user will now assume that the account name or password was mistyped 
and will try again...this time (scince the real operating system is in 
control) with more success.You can see a diagram of the way these steps are 
accomplished

 ___________________   
 |   Clear Terminal   |
 |       screen       |
 |____________________|
           ||
  _________||_________
 |  Print Compuserve  |
 |      Computer      |
 |_____ Network ______|
           ||
  _________||_________
 |   Print "ENTER     |
 |     PASSWORD"      |______
 |____________________|      |
          ||                 |
 _________||_________        |
 |  PASSWORD ENTERED? |__NO__|
 |____________________|   
          ||_YES
 _________||_________
 |   SAVE PASSWORD    |
 |    INFORMATION     |
 |____________________|
          ||
 _________||_________
 |   PRINT "LOGIN     |
 |     INCORRECT      |
 |____________________|
          ||
 _________||_________
|   LOG OFF/RETURN   |
|    CONTROL TO      |
|  OPERATING SYSTEM  |
|____________________|

 4) CALL FORWARDING

 Many people use call forwarding by special arrangement with the phone 
company.When a customer requests call forwarding, the phone company uses 
its computer to forward all the customers incomeing calls to another 
number. Lets say, for example, that you want calls that come to your office 
phone to be forwarded to your home phone: A call from you to the phone 
company,some special settings in the phone companys computer, and all 
calls to your office will ring at your home instead.This little bit of help 
from the phone company is another tool used by hackers. Lets say you thought 
that the computer you were hacking into was being watched-because the 
sysop might have seen you and called the fed's and your sort of bugged by 
this nagging feeling that they will trace the next hacker that calls, 
just call the phone company and ask for call forwarding, pick a number, 
(ANY NUMBER) out of the phone book and have your calls forwarded to that 
number,Hea,Hea, the number you picked is the one that will be traced to,
not yours, so you could be hacking away,they think that they have traced you, 
but actually the number you had your calls forwarded too. they enter chat mode
and say (YOUR BUSTED!!!!, WE'VE TRACED YOUR PHONE NUMER THE FEDS ARE ON THE 
WAY!!), You could reply (Hea, SURE YA DID! I'D LIKE TO SEE YA TRY AND GET ME! 
GO AHEAD!) ,that wont seem very important to them at the time, but it will 
sure piss them off when they bust the wrong guy!  

5) RAPID FIRE

 Memory-location manipulation can be helpful, but there is another, more 
powerful,possibility, in some cases: the Rapid-fire method.To understand how 
this methos works, you have to know something about the way operationg 
systems work.When a user enters a command, the operating system first places 
the command in a holding area, a buffer, where it will sit for a few 
millionths of a second.The system looks at the command and say's "Does this 
person really have authorization to do this, or not?" Then, the command 
sits there a few thousandths of a second while the system runs off to 
check the user's authorization.When the system comes back to the command, 
it will have one of two possible answers: "OK, GO AHEAD," or "SORRY, 
GET PERMISSION FIRST."

 Once you are on a system that handles things this way, you can use the 
rapid-fire method to change the command while its sitting in the buffer,
waiting to be executed. If you can do this,you can do anything.You can enter 
a command that you know will be approved, such as "tell me the time." As soon 
as the system runs off to verify your right to know the time,you change 
the command in the buffer to something you know would not be approved-perhaps
"give me a list of all the passwords." When the system comes back with an 
"OK, go ahead," it responds to your second command, not the first. Of course,
this exchange has to be done very rapidly,but most systems existing today 
can be fooled by this trick. The question is,how easy is it to do, and how 
much authority do you need? I know of one system that let this one slip.

These are certainly not all the hacker's little secret tricks and tool's,
You will probably figure out some better, more efficiant,hacking techniques.

GOOD LUCK!!!!!!
L O G A N - 5
<------------------------------------------------>

 �������������������������������������������������������������������������������������������������������������������������

HP 2000 Part 4: Files by Blitzoid and Galactus

=======================================
=                                     =
=      HP 2000 PART 4 (FILES)         =
=                                     =
=             CAPTURED BY             =
=                                     =
=      BLITZIOD ?? & GALACTUS **      =
=                                     =
=                 of                  =
=                                     =
=       THE ELITE HACKERS GUILD       =
=                                     =
=======================================

* FILES *

BASIC FORMATTED FILES ARE ESSENTIALLY THE SAME AS
DATA STATEMENTS, THEY BOTH HAVE POINTERS THAT MOVE ALONG THE DATA
HERE IS AN EXAMPLE OF A PROGRAM USING THE DATA STATEMENT    :

10 READ X
20 PRINT X
30 DATA 1,2,3,4,5,6,7,8,9,10
40 GOTO 10
50 END

WHEN THIS PROGRAM IS RUN THE DATA IS READ IN LINE 10
FROM THE DATA STATEMENT IN LINE 30.
AFTER THE '1' IS READ FROM THE DATA STATEMENT THE POINTER IS
MOVED TO THE '2' AND SO ON.  WHEN THE FINAL PIECE OF DATA IS READ
AND THE POINTER IS MOVED BEYOND THE '10' THEN YOU WILL GET THE
ERROR MESSAGE:      OUT OF DATA IN LINE 10       
THIS IS ESSENTIALLY THE WAY FILES WORK.
BUT FILES HAVE MANY MORE CAPABILITIES THAN DO DATA STATEMENTS

LET'S LEARN HOW TO CREATE A FILE, OK?

TO CREATE A FILE ALL ONE MUST DO IS TYPE IN CRE- THEN THE
NAME OF THE FILE, AND HOW LONG IT MUST BE.  FOR EXAMPLE IF I WANTED
TO CREATE A FILE NAMED 'DAVID' THAT IS 5 RECORDS LONG I WOULD TYPE IN
CRE-DAVID,5
THEN HIT 'RETURN'

WHENEVER YOU CREATE A FILE THE COMPUTER RESERVES THE NUMBER OF
RECORDS YOU CREATED IT ON THE DISC.  SO IF YOU CREATE A FILE THAT
IS 50 RECORDS LONG, YOU HAVE USED 50 RECORDS OF DISC SPACE, WHETHER
YOU USE THE WHOLE FILE OR NOT.

NOW I WILL SHOW YOU A PROGRAM THAT WILL PRINT ON YOUR FILE.

 5 DIM A$(20), B$(20)
10 FILES FIL1
20 PRINT 'NAME';
30 INPUT A$
40 IF END#1 THEN 85
50 READ#1,1
60 READ#1;B$
70 GOTO 60
85 IF END#1 THEN 110
90 PRINT#1;A$,END
100 STOP
110 PRINT'FILE FULL'
120 END

BY THIS TIME YOU ARE WONDERING WHAT THAT MESS IS, RIGHT ?
HERE IS AN EXPLANATION  

STATEMENT #                       MEANING
10          OPENS THE FILE THAT IS TO BE USED, IN THIS CASE THE NAME OF
            THE FILE IS 'FIL1'.  THIS STATEMENT IS TELLING THE COMPUTER
            WHAT FILE WE WANT TO USE FOR THIS PROGRAM
            FIL1 IS REFERRED TO AS #1 AS SEEN IN LINES 40,50 & 60
            IF MORE THAN ONE FILE WAS USED LINE 10 WOULD LOOK LIKE
            THIS  FILES FIL1,FIL2.  THEN FIL2 WOULD BE REFERRED
            TO AS #2.  UP TO 16 FILES CAN BE USED IN ONE PROGRAM
30          INPUT NEW NAME TO BE PRINTED ON FILE.
40          THIS STATEMENT 'IF END' SETS UP THE IF END 
            CONDITION.  THIS MEANS THAT WHEN THE FILE PIONTER GETS
            TO THE END OF  DATA IN THAT FILE THEN GOTO 85
50          THIS MEANS TO READ THE FIRST RECORD AND THE
            FIRST ITEM OF THE FILE, IN OTHER WORDS THIS
            THIS SETS THE FILE POINTER BACK TO THE BEGINNING OF THE
            DATA.
            BY USING THIS STATEMENT YOU CAN BE ASSURED OF STARTING
            AT THE BEGINNING OF THE DATA IN THAT FILE
60          READS DATA FROM FILE#1, SOMEWHAT LIKE THE 'READ' USED
            WITH DATA STATEMENTS.
85          SETS UP ANOTHER IF END CONDITION TO CHECK FOR THE END OF
            FILE.  IF ANOTHER EOF MARKER IS ECOUNTERED THEN GOTO
            LINE 110.
            END-OF-FILE MARKERS ARE DEFINED MORE PRECISELY LATER.
90          THIS STATEMENT PRINTS THE NEW NAME (A$) ON THE FILE,
            THEN PRINTS AN END OF FILE MARKER ON THE FILE.
            THE END OF FILE MARKER ENABLES THE COMPUTER TO TELL
            THROUGH THE READ STATEMENT (LINE 60) WHEN THE END OF
            DATA IS REACHED

HERE IS A FLOW CHART OF THAT PROGRAM:

1.  INPUT NEW NAME -----------2.  READ DATA FROM FILE

3.  IF END OF FILE #1 THEN 4 -----GO BACK TO 2.
                                 !
                    4.  IF END#1 THEN 7
                                 !
5.  TRY TO PRINT NEW NAME ON FILE, IF SUCCESSFUL (MEANING FILE IS
    NOT FULL) THEN 6.  IF UNSECCESSFUL (MEANING FILE IS FULL) THEN 7.
                                 !                            !
                                                              !
                                 !            7.  PRINT'FILE FULL'
                             6.  STOP                         !
                                                          8. END

OK, LET'S MOVE ON TO GET A LISTING OF YOUR FILE

05 DIM A$(20)
10 FILES FIL1
20 IF END#1 THEN 70
30 READ#1,1
40 READ#1;A$
50 PRINT A$
60 GOTO 40
70 END

THIS IS A RATHER SIMPLE PROGRAM, IT GOES LIKE THIS;
YOU SET UP THE IF END CONDITION, THEN READ STARTING AT THE
BEGINNING OF THE FILE.  READ THROUGH THE FILE AND PRINT
EACH SEPARATE PIECE OF DATA (LINES 40 & 50). WHEN ALL THE
DATA HAS BEEN READ THROUGH, IT FALLS THROUGH TO LINE 70, BY
THE CONDITION SET UP IN LINE #20 AND AT THIS POINT
EXECUTION IS TERMINATED.

*  END OF FILE DISCUSSION  *

HERE IS SOME ELLABORATION ON WHAT YOU HAVE LEARNED SO FAR
ABOUT BASIC FORMATTED FILES.

 THE EOF MARKER IS WHAT THE IF END CONDITION IS USED 
WITH.  THE EOF MARKER DESIGNATES THAT THE END OF DATA HAS BEEN REACHED.
AS MORE DATA IS PUT INTO A FILE.���������������