Re: New hooks for sock structure

From: Wayne Salamon (wsalamonat_private)
Date: Wed Jul 10 2002 - 05:07:39 PDT

  • Next message: Wayne Salamon: "Re: New hooks for sock structure"

      Thanks for the comments. See my reply below.
    
    On Tue, 9 Jul 2002, Chris Wright wrote:
    > After brief review I'll need to dig in deeper and understand how this
    > is useful.  I was initially confused by the naming, since it's really
    > done on the accepting side of a stream rather than the connecting side
    > (at least the socket_sock_connect bit, but the unix_stream_connect is
    > called from the client side of the socket, right?).  Of course, I must
    > ask...is there no other way? ;-)
    >
    
      In the original SELinux prototype, the client security info was
    maintained in the sock struct. In the current LSM SELinux, we tried to
    avoid using the sock structure and implemented a list of connection-SID
    mappings, but this is prone to leak memory and is not very elegant, and
    doesn't always work in the UNIX case. See
    http://www.nsa.gov/selinux/doc/module/x2043.html for a detailed
    discussion. So we decided to add security info to the sock struct in the
    same manner as the original prototype.
    
    > It seems reasonable to keep label from skb up through socket.  I am not
    > clear that SCM isn't useful enough in the AF_UNIX family, but like I
    > said, I haven't looked at this very thoroughly.
    >
    
      In the UNIX case, we're not using the new hook. It's enough to just add
    the new sock structure as a parameter to unix_stream_connect() hook as
    part of this patch.
    
    >  - the save/restore bit seems a little funky
    
      Yea, but we wanted to centralize the call to the
    socket_sock_alloc_security() hook in the sock allocator (sk_alloc).
    Therefore, we need to preserve the security field around the cloning of
    the newsk from the existing sk structure.
    
    >  - if (sk != NULL ), just do if (sk) (which is already checked above,
    >    although collapsing into one check might not be worth it considering
    >    the zero_it.)
    >
    
      Hmm..., is this a coding style comment, or do you have other concerns? I
    realize that the check above my check is of your form, but
    __kmem_cache_alloc() returns NULL on failure, not zero. Other parts of the
    kernel use both forms.
    
    Wayne
    
    -- Wayne Salamon
     wsalamonat_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 : Wed Jul 10 2002 - 05:10:36 PDT