[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "user" and "network layer" security mechanisms.
In article <9608202111.AA25177@hickory.pa.dec.com> Ted Wobber wrote:
>In a Mandatory Access Control world, perhaps this 5% shortfall is
>a significant problem.
In a MAC environment, such as a CMW, it is a hard requirement in the TCSEC
(including derivatives such as Red Book and equivalent specifications) that
the security attributes of objects be dependably propogated to all the
legitimately communicating endpoints.
Identity of the SA is just another security attribute to propogate. MAC
controls already require significant changes deep inside TCP/IP stacks.
(e.g. so that IP packets get correctly labeled using IPSO). Those changes are
so significant that it shouldn't be much additional work to add IPsec with
user-oriented keying as well.
As one of the few people on this list who have actually written both
IPsec code and MLS OS code, this is not idle speculation on my part.
I'm pretty sure that I could implement it inside BLS 8.09, for example,
(if I had access to BLS source code).
It is possible to design an MLS OS that makes IPsec difficult,
but the problem there is poor OS design not the IPsec per se. It is
similarly possible to design an OS that makes networking protocols
difficult, but that doesn't mean the TCP/IP specs are bad.
Now in non-MLS systems, unique SAs are also not very hard to implement. The
NRL IPsec code has always supported them, by way of providing an existence
proof.
>However, I am concerned about your comments on the cost of "propagating"
>user-level identity within the network code. How much of this cost
>do you attribute to the nature of your MAC environment? I imagine
>that for some protocol elements the job might have been straightforward,
>and for others not. Does the majority of the cost come from fitting
>square pegs into round holes?
Using BSD as an example, the kernel knows which process opened a socket and
also can dependably determine which uid owns that process, thereby determining
which uid should be associated with that socket. A privileged process can
fork/exec and change its identity after the socket has opened, but this is not
necessarily a security problem since it is a _privileged_ process. If an
unprivileged process can change its identity at will, then there are bigger
security problems within that system than IPsec could hope to help with.
In the BSD code, one can store security information about a socket inside
socket state. A pointer to that socket state can be added to the mbuf chain
that travels downward through the system. At points where the per-socket
security information needs to be checked, the backpointer can be used to read
it from socket state. Inbound data first gets checked against the minimum
system security level roughly during ip input processing. It gets checked a
second time, now against the security information stored in the destination
socket state, just before its handed up to the application. Adding identity
information to the security information associated with a socket is
straight-forward.
Ran
rja@cisco.com
Follow-Ups:
References: