Re: Model for security

[mcnabb () argus-systems com (Paul McNabb)]

There are problems with treating "the network" as "the computer"
in that a standard network today doesn't share information about
the properties of active agents, i.e., those processes responsible
for the packets being sent out.

An OS knows everything about every process.  It is possible to keep
a table of the state of each process, and this table is used for
making all kinds of decisions: scheduling, security, etc.  On today's
network, the best you can hope for is to be able to identify the host
address and then rely on high level applications to exchange the
attributes they think are important.

In addition to needing a mechanism for passing the "complete" set of
attributes, you must be able to guarantee two things: authentication
and integrity.  That is, you have to be able to identify the other
side and you have to know that nothing got modified en route.  A third
issue, privacy/confidentiality, is important for some issues but not
from a functionality point of view.

The OS security vendors ran up against this problem in 1990 when they
wanted to extend their B1 systems across a network.  The solution
they came up with involved a new layer in the protocol stack that
sits above TCP.  This allowed the passing of an unlimited number of
attributes (in tokenized form) and for the translation or mapping of
the attribute based on the type of system or vendor or security model
at each end of the connection.

This protocol, Security Attribute Modulation Protocol (SAMP), was
adopted by the security groups at HP, DEC, SUN, SecureWare, Argus, 
Sequent, Harris, SCO, and others.  If you have SAMP, or something
like it, with encryption (to provide authentication, integrity, and
confidentiality), you can actually build a security model that
extends beyond a single host.  Using SAMP, when a packet comes in
I know at least the following about the sender of the packet: user
ID, group ID, secondary group IDs, B1 security labels, process ID,
host ID, audit ID, audit info, IL (a CMW security label), clearance
(another B1 label), and privilege sets.  The privilege set is a
very interesting piece of information because it tells you what this
process could do back on its own host: bypass read bits, perform
chmod system calls, perform mknod system calls, etc.  With all of
this information, you can create a process to handle the request
that is a copy of the process on the source machine.  It's not a
perfect solution but it gets the job done pretty nicely and it is
quite extensible.

BTW, several of these networked systems have completed evaluation,
both in the US and in Europe.  Any evaluation today that does not
include a networking component is way behind the times.  SAMP works
on, and has been evaluated on, non-B1 systems as well.  These systems
exchange the UID, GID, process ID, privileges, etc. but not the B1
attributes.

I should add that most (I hope all) of these systems allow transparent
communication both with SAMP hosts and with standard hosts. They
usually allow an administrator to assign default attributes for packets
coming without a SAMP header or from untrusted hosts or interfaces.
Many also allow firewall-like filtering based on these attributes as
well.  A firewall running this type of networking can also mark packets
coming in (based on interface, IP address, etc.) and extend this
information about the source into the internal network to hosts that
may actually need to handle the packet.  Some of the security attributes
can be passed using IP security options as well.

A B1-level firewall can do a lot more than just protect its own files
but not all "B1 systems" do "B1 networking".  Caveat emptor.

paul

>  Date: Thu, 19 Feb 98 11:16:48    
>  From: John McDermott <jjm () jkintl com>
>  
>  OK,  I think we need some new sort of model, too.  I guess I need an 
>  earlier starting point, though: what form should the model take?
>  
>  Here are some (unordered) thoughts we could perhaps use as a starting 
>  point:
>  
>  I'm more struggling with the form than the content at this point.  That is, 
>  do we want to look at an access model (as paragraph one alludes to below) 
>  or do we want something else?
>  
>  Reading paragraph one below again, it seems as though the "timesharing" 
>  system isn't so far fetched a concept today as it seems, if we consider 
>  "the network is the system".  Then it *sort of* distributes the system 
>  around.  The problem with that is that we then have N (where N is not too 
>  small) different implementations of each part of the system, etc.
>  
>  So in general, I think the model needs to deal with the distributed nature 
>  of computing as we now have it.  Maybe there is a heirarchical structure 
>  of:
>       User
>        |
>       Local application (e.g. client)
>        |
>       Local system (esp. the OS)
>        |
>        | -- is the information about how the local and remote systems
>        |      connect significant?
>        |
>       Remote system (esp. the OS)
>        |
>       Remote application (e.g. server)
>  
>  This 5-tuple (is that enough?, too much?) might desrcibe an "association" 
>  for which some attributes might be enumerated.
>  
>  Anyway, I hope this servers as a starting point for some thought...
>  
>  --john

---------------------------------------------------------
Paul McNabb                     Argus Systems Group, Inc.
Vice President and CTO          1809 Woodfield Drive
mcnabb () argus-systems com        Savoy, IL 61874 USA
TEL 217-355-6308
FAX 217-355-1433                "Securing the Future"
---------------------------------------------------------