Re: Patch: Socket hooks

From: Chris Vance (cvanceat_private)
Date: Wed Jul 25 2001 - 07:34:54 PDT

  • Next message: Greg KH: "Re: Audit patch split into 5 parts"

    I find it hard to believe that there have been no additional comments on
    this patch.  Should I assume that everything is fine and that it will be
    commited shortly or should I assume that everyone has been too busy
    thinking about file descriptors to take a look at it?
    
    Off-list I have received only a couple comments.  One asked if it would be
    useful to have a post_accept hook.  I originally had hooks for post_accept
    and post_connect, but removed them due to a lack of usefulness. 
    
    In the case of connect, too much processing has occurred by the time a
    post hook can be placed in net/socket.c - the same is likely true for
    accept as well. It seems inappropriate to have the ability to make an
    access-control based decision after the fact -- added to which is the
    issue of unrolling any performed operations.  
    
    This moved me to make the two post hooks return void and simply be used to
    update state information.  I believe all state information can be
    maintained by the normal hook (in both cases, the new socket is
    available).
    
    I'm also a bit unclear on the implications of race conditions/timing with
    regards to the connection being established and then later shut down. Can
    another application thread gain access to the resource following
    establishment but before a post function can deny and shut down the
    socket? Again this leans towards post functions that return void - and
    hence have reduced utility. 
    
    For these reasons, I decided NOT to include post_accept or post_connect
    hooks.  If someone else can determine a way to safely include them, or
    suggest alternate locations (netfilter?) I would welcome the help. 
    
    Off-list, Steve Smalley also added: "the original SELinux prototype
    inserted code directly at the TCP layer to control connection
    establishment during the three-way handshake.  However, LSM currently
    doesn't have any hooks in the TCP/IP implementation, and we are trying to
    investigate the extent to which we can implement the SELinux controls via
    a combination of hooks in the socket layer and hooks in the netfilter
    code.  We ultimately may need to insert hooks directly into the TCP
    implementation as well, but we're trying to minimize such changes in order
    to ease acceptance by the kernel developers."
    
    As he explained (better than I could have), this is what we are currently
    exploring. However, it should not affect the acceptance of this patch.
    These issues will be presented to the list in a future patch, independent
    from this one. 
    
    Just to to be perfectly clear, this patch is separate from the ongoing
    netfilter/skb/netdevice work and does not include post_accept or
    post_connect hooks. 
    
    chris.
    
    On Mon, 23 Jul 2001, Chris Vance wrote:
    
    > 
    > Attached is a patch that is identical to the first, with the exception
    > that the extra user-space parameters have been removed from the accept and
    > setsockopt hooks.  This new patch should replace the previously posted
    > one. 
    > 
    > chris.
    > 
    > On Fri, 20 Jul 2001, Greg KH wrote:
    > 
    > > On Fri, Jul 20, 2001 at 04:09:31PM -0400, Chris Vance wrote:
    > > > 
    > > > Something escaped my first pass.  Note that two of these hooks have
    > > > parameters that are user-space variables - accept and setsockopt.  In the
    > > > first case, accept, they should be removed. In the second case,
    > > > setsockopt, it's not clear whether an LSM module would care precisely what
    > > > value is being set.  It would need to be copied into kernel memory and the
    > > > possibly of a race condition exists. 
    > > > 
    > > > Perhaps removing these paramters would be the safest thing to do.
    > > 
    > > I agree.  Keeping lsm modules from having to handle userspace variables
    > > is a good thing.  Where ever possible I think we should try to avoid it.
    > > 
    > > Other than that, the patch looks nice.  However I don't profess to know
    > > anything about the network stack code :)
    > > 
    > > Anyone else want to comment if these hooks will work out for their
    > > projects?
    > > 
    > > thanks,
    > > 
    > > greg k-h
    > > 
    > 
    
    
    
    
    _______________________________________________
    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 Jul 25 2001 - 07:37:48 PDT