Re: 2001_05_09 patch against 2.4.4

From: Jesse Pollard (pollardat_private)
Date: Wed May 16 2001 - 07:07:17 PDT

  • Next message: Chris Wright: "Re: 2001_05_09 patch against 2.4.4"

    ---------  Received message begins Here  ---------
    
    Chris Wright <chrisat_private>:
    > * Chris Evans (chrisat_private) wrote:
    > > 
    > > > The current scheme is to control access to the kernel's core data
    > > > structures.  Some of this requires hooks in syscalls, other places this
    > > > does not (the whole networking hook system will not be near the single
    > > > network syscall, from what I think Chris W. has in mind.)
    > > 
    > > I think the most important "object" to hook in the networking land is the
    > > "network interface". Quick cheesy example:
    > > - eth0: labelled as low security
    > > - slip0: labelled as high security
    > > /etc/very/secret: labelled as sensitive, high security
    > > process pid 100: has /etc/very/secret open, marked as sensitive
    > > process pid 100 does socket()
    > > process pid 100 tries to bind to IP address owned by eth0 => EPERM!!
    > 
    > I agree the device is one piece that we need to watch, but i'm not sure that
    > it is the most important.  Look at packet filter firewall rules, they are
    > largely about complete tuples not just devices.  In your example, eth0 may
    > need finer granularity than low security.  Perhaps it is fine to talk out
    > eth0 to mysercurehost.com on port 22 using tcp even if I have
    > /etc/very/secret open.  I'd like to be able to support tcp connect/accept
    > and udp send/recv to/from host:port via device (howz that for non-sense? ;-)
    
    Nope - very reasonable. It calls for IPSec layers on TCP, and CIPSO like
    identification as well. The packet filter firewall rules appear to be acting
    in the place of IPSec.
    
    I would like even more integration....
    
    local user (running secret on host W) attempts to connect to host X.
    
    1. capability test locally determines that user is allowed network access...
    
    2. MLS combines access request with security label (secret) and passed to
       IPSec.
    
    3. IPSec security association (SA) determines that encryptions of session
       (or packet) is mandatory - policy decision between the local facility
       and the remote facility containing X (and the requirements of the local
       security label and encryption negotiation between W and X...).
    
    4. Remote facility decrypts (based on local SA) examines security
       identification and extended security header for compatable translation of
       of label (passed from W).
    
    5. User identification (contained in extended header) matched to local user
       on X.
    
    6. MLS determines if user (on W) is authorized the label (translated from
       host W label).
    
    7. connection between user on host W and service (on host X) established.
    
    The key is that the network interface may operate at multiple levels depending
    on the host-host connection. Protection is identified by the IPSec layer
    to determine the amount of protection required.
    
    This also permits the unencrypted connection if it is reasonable (host
    W and X are both on internally controled networks AND under the same security
    policy AND....).
    
    -------------------------------------------------------------------------
    Jesse I Pollard, II
    Email: pollardat_private
    
    Any opinions expressed are solely my own.
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed May 16 2001 - 07:08:34 PDT