------------------------------

Subject: The Ultimate Interface: Hackers and the Private Sector
From: Dark Adept
Date: Tue, 23 Oct 90 22:19 CDT

********************************************************************
***  CuD #2.09: File 7 of 8: Hackers and the Private Sector      ***
********************************************************************

          The Ultimate Interface:  Hackers and The Private Sector

A major problem in Cyberspace is the lack of communication between hackers
and non-hackers.  Corporations are fully entitled to their privacy, and so
they feel threatened by the hacker "menace."  They view the hacker as the
enemy, and so they persecute him. This is a valid belief since history
shows that when a group does not understand another group, they try to
destroy it.  Saying this is valid does not make it right.  If hackers and
corporations and security companies and software companies, etc., etc.,
etc. were to overcome their differences much could be done.  By trading
bits and pieces of knowledge, the two opposing groups could together
develop revolutionary advances in computing that would benefit all.  The
problem is to get the two groups to trust one another.  In some upcoming
G-Philes and submissions to CuD, I hope to break down this barrier of
resentment by crossing over the lines of the Underground into the "real"
world and providing valuable information about systems, security,
interfacing, etc. from a hacker's/member-of-the-underground's point of
view.  I hope others will follow suit, and that the private sector will
reciprocate by allowing technical information to flow into the Underground.
Ultimately, I hope that there will be a rapport between hackers and members
of the private sector so that we may learn from each other and make the
best use possible of this greatest of inventions, the computer.  Without
further delay, then, I present the first of what I hope will be a long and
successful series of articles.  These must be short since they are merely
articles, but I have planned a few full-length works that will be more
in-depth; I will send them to the CuD archives as they become available.  I
hope you enjoy them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

            System Security:  Security Levels and Partitioning

                             by The Dark Adept

Traditionally, security levels are used to prevent a user from gaining
access to areas where he lacked legitimate interest.  They also have
another very useful purpose that is seldom recognized.  They can be used as
a firewall of sorts to stop the spread of viruses and the destruction of
files by an intruder.  A good analogy of this theory is ship design.  When
a ship is designed, the lower compartments are designed separate from each
other so that if the hull is punctured, the flooding compartment may be
sealed off thus localizing the damage and stopping the ship from sinking.
In the same way accounts should be assigned security levels.  However, if
the accounts are fully isolated from one another, it is too restrictive to
be of any real use.  A user in Accounting would not be able to access the
records from Personnel to find an employee's rate of pay, for example.
Optimally, then, one would want a balance between freedom and security.
This optimal assignment of security levels is accomplished through a
two-stage step.

The first stage is the creation of generic accounts.  Many computer
systems, such as those of schools, use generic accounts as their sole
source of security.  This is VERY dangerous.  By generic accounts, I mean a
set of basic accounts where each member has certain privileges assigned to
it that differ from the other members.  For example, in schools the
teachers often receive one type of account, and students another.  Besides
the systems operator's account, these are the only two types of accounts
available.  The teachers have a wide-range of freedoms including being able
to look into files that don't belong to their department since they can be
trusted. The students have a limited amount of ability, mostly restricted
to accessing their files only.  But what happens if an intruder grabs a
teacher's account?  You got it, he has access to A LOT of stuff!
Obviously, this won't do.  However, generic accounts are useful if used in
combination with other devices.  This leads to the implementation of the
second stage: security levels.

Example:  Let X, Y, and Z be generic accounts in system S with the
following maximum abilities:

X can access file areas A, B, C, D
Y can access file areas B, D, J, K
Z can access file areas B, C, J, L

Assume some User, u, needs access to file areas B and L alone.  Assign him
account type Z with security modifications such that he may access only
file areas B and L.

This results in User u being restricted to the proper file areas, B and L,
but allows ease of modification later if he needs access to areas C or J.
It also allows for the greatest amount of security since his account type
is Z so by definition he cannot access file areas A, D, or K without
receiving a new account.  Therefore, if an intruder takes control of
account u, he cannot destroy more than areas B and L without modification.
The most he can modify account u to have access to is areas B, C, J, and L.
Therefore the damage will be localized to file areas B, C, J, and L.  The
only way he can enter the other areas is to get a new account. This is much
more difficult than modifying one he already has.

The same sort of setup may be applied to commands, usage times, dialup
ports, etc.  For example, say the editor of a newspaper has account Z that
has maximum port capability of T, t1, t2, t3 where T is a terminal in his
office and t1, t2, and t3 are outside lines.  At first he is assigned a
security level that allows access to T only so his account cannot be
accessed from intruders outside thus stopping someone from deleting all of
tomorrow's edition.  Now, if he must go on location somewhere, it would be
a simple matter to modify his account to give him access to t1 so he can
call up and review the submissions.  Yet, again, if there exist ports t4,
t5, etc., these would NEVER be able to access the files since account type
Z is incapable of being accessed through these ports.

What follows here is a mathematical model of account partitioning using
concepts of discrete mathematics.  Since this is a text file and cannot use
graphics characters, some common mathematical symbols must be defined using
regular characters.

Symbols:
--------

|    = "such that" (ordinarily a vertical bar)
\e\  = "is an element of"  (ordinarily an emphasized epsilon)
<==> = "if and only if"

Model:
-----

Let S represent a computer system.

Let S1 be a set of different areas of interest in a computer system.  This
is modelled by S1={a1,a2,a3,...,an} where n is some integer, and a1,a2,
a3,... are the areas of interest in S.

Let S2 be a set of different user accounts in a computer system.  This is
modelled by S2={u1,u2,u3,...,uq} where q is some integer, and u1,u2,
u3,... are the user accounts in S.

Let x \e\ S2.  Let y \e\ S1. Let r be a relation on S defined as this:

xry <==>  x \e\ S2 | x has access to y.

Now r becomes a partitioning relation on S2.  The function that defines r
is determined by how the operator wants his accounts set up.

Further, the equivalence class of x, [x], defines the generic account.

Example: Say S has accounts u1, and u2.  It also has areas of interest a1,
a2,a3.  Now say the operator wants u1 to have access to a1 and a2, and u2 to
have access to a1 and a3.  By defining r in the proper manner he gets:
r ={(u1,a1), (u1,a2), (u2,a1), (u2,a3)}.  Now [u1]={a1, a2} and
[u2] = {a2, a3}.  Thereby defining the generic accounts.

Now let G be the set of all of the equivalence classes determined by xry
that define generic accounts in S.  This is seen as G={[x]|x /e/ S2}.

For clarity, let g1 = [u1], g2 = [u2], ... so we have G={g1,g2,...gq} where
q is some integer.

Now let d \e\ G.  We define w to be a relation as such:

dwy <==> d \e\ G | d has access to y.

Now w becomes a partitioning relation on G.  The function that defines w
is determined by how the operator wants to implement a generic account
for a particular user.

Further, the equivalence class of d, [d], defines the specific user
account.

Example:  Say S has generic account g1 set up.  It has areas of interest
a1, a2, and a3.  g1 is partitioned in such a way that it can only access a1
and a3.  Now say the operator wants a certain holder of a generic account
type g1 to have access only to a1.  By defining w in the proper manner he
obtains: w={(g1,a1)}.  Now [g1]={a1} thereby defining an appropriate user
account.

As some may have noticed, accounts can be partitioned ad infinitum.  In
most cases I have found two partitions to be sufficient.  An interesting
adaptation is also to use this method to define what users have access to
which commands.  It again allows much room for change while keeping things
safely separate.

The ultimate safety would come when the first partition is defined in the
operating/timesharing system itself.  For example, if Unix (Tm of AT&T)
came with say 30 different file areas and accounts accessing those areas in
specialized ways, then even if an intruder grabbed the root account, he
could not change the first level of partitioning to access all those
accounts.

As I hope I have shown, the proper use of generic accounts and security
levels allows the optimum balance of security and ability.  By properly
partitioning accounts, the system operator can isolate a problem to a
relatively small area allowing faster restructuring afterward.

I hope you have enjoyed this article.  I can be reached for comments,
criticism, and E-mail bombs at Ripco BBS (312)-528-5020.  Also, if you
liked this article, you may comment to Jim Thomas (editor of CuD) and he
can pass the general reception on to me.

Written 10/21/90 in Chicago, IL -- The Dark Adept

********************************************************************
                           >> END OF THIS FILE <<
***************************************************************************


Downloaded From P-80 International Information Systems 304-744-2253 12yrs+