[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "user" and "network layer" security mechanisms.

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
 A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
 dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
 MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
 Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
 DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
 AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
 A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
 aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
 AWd7XZSqrLcfeKkY0N7/FKl/aheROPx38aIYGK+TN5naLv38zvqbH8Ofrk22FKtZ
 BqqzUxt2qwYySKMBl7zz42U=

>Ran Atkinson wrote:
>
>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).

So have I.  I also wrote most of the BLS 8.09 networking code.  It
is precisely this experience that makes me rather insistent on this
issue.   Adding user-level SA tracking as another security attribute
within an MLS stack would be easy -- only because they have invested
tremendously in building an infrastructure to pass such attributes up
and down the stack.

>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.

And then again, there are services that manage a pool of sockets within
the kernel, such as any kernel RPC service and many implementations of
the TSAP.  These sockets are opened and initialized by daemon helpers when 
the service is initialized.  They are used by whichever process requests 
access to the service.  The approach Ran gives above will authenticate the 
user of the service as if he/she were the daemon process, unless, of course,
the application is modified to understand the kernel hacks required for 
IPSEC user authentication.

The question remains, is 95% coverage sufficient?

Charlie Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
References: