Re: Patch: Socket hooks

From: James Morris (jmorrisat_private)
Date: Fri Jul 20 2001 - 19:32:00 PDT

  • Next message: David Wagner: "Re: Changes to LSM phase 1 for audit."

    On Fri, 20 Jul 2001, Chris Vance wrote:
    
    > This patch makes no attempts to secure skbuffs or network devices.  We are
    > still working towards an implementation that is most likely to be accepted
    > by the kernel folks. To that end, we are going to see what we can do with
    > the netfilter code rather than directly modifying the ip input/ouput
    > routines or modifying the sk_buff structure (which apparently would be
    > difficult to gain approval for).  If anyone has any relevant insight, I
    > would welcome it.
    
    Implementing LSM hooks via Netfilter would provide a simple way to make
    access decsisions and possibly modify packets (e.g. encryption) at useful
    points within the network layer (namely: prerouting, forwarding,
    postrouting, local in and local out), but it may not help if there is a
    need to propagate security context to the transport layer.
    
    For example, you may want to make an access decision for incoming packets
    based on the user who is about to receive them.  This is not known at the
    network layer, and the decsision can only be made further up in the stack,
    after the network layer header has been pulled from the skb.
    
    Also, there is the issue of packet labeling, which is often performed at
    the network layer (e.g. via IP options) which may need to be propagated to
    the transport layer for each datagram and sub-stream segment.
    
    There may even be a need to label packets differently depending on whether
    they were processed with a specific type of network device (keeping in
    mind the trend towards more complex network processing being done in
    hardware).
    
    As far as I can tell, the best way to acheive this for the general case is
    to attach an opaque blob to the skb.  It's very difficult to guess how the
    network maintainers would react to this.  From my reading of comments
    previously made on similar issues, it seems that objections may include:
    
    - lack of generality
    - poor design (e.g. protocol layering violation)
    - performance reduction caused by bloating network structures and the
      finely tuned network fast path (good people have sweated blood on this :-)
    
    Addressing the first two issues, I would suggest that LSM is a potentially
    fundamental aspect of the kernel and is thus is part of a general
    mechanism, and that security context needs to be propogated between
    network layers for MAC security models (at least).
    
    For performance, it is very difficult to know unless there is at least
    some code to look at.  It is possible that the LSM hooks may need to be
    implemented as macros in the networking code.  Those who wish to run
    things like Mindcraft tests would simply then be advised to disable high
    assurance security features.
    
    Anyway, I will have a look at this over the weekend, and see if I can come
    up with something which might be useful as a discussion point.
    
    - James
    -- 
    James Morris
    <jmorrisat_private>
    
    
    
    _______________________________________________
    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 : Fri Jul 20 2001 - 19:33:32 PDT