Re: Two new network hooks

From: Chris Vance (cvanceat_private)
Date: Tue Mar 19 2002 - 09:44:21 PST

  • Next message: I.P. Park: "Hello - a new member from Panasonic"

    On Mon, 18 Mar 2002, Chris Wright wrote:
    
    > * Chris Vance (cvanceat_private) wrote:
    > >
    > > Attached is a patch which adds two hooks that were required by SELinux to
    > > support labeled networking.  Does anyone have any suggestions, comments,
    > > or criticism?
    > >
    > > * post_accept - placed in sockets.c:sys_accept, just before return.  This
    > >   allows us to update socket labels for the newly created socket.  The
    > >   original listening socket is relabeled in the sock_rcv_skb hook during
    > >   the handshake (peer label updated).  This information needs to be
    > >   copied into the newly created socket after the accept.
    >
    > this hooks makes sense to me, as it is similar to the post_foo hooks in
    > the VFS layer.
    >
    > > * recv_datagram - placed in datagram.c:skb_recv_datagram just before the
    > >   skb is returned (non-null/non-error case only).  This seems to be the
    > >   only time that there is a association between the current process, the
    > >   socket, and the skb.  SELinux will use this to copy the socket source
    > >   SID and the socket message SID into the process security structure so
    > >   that it may be returned by extended socket calls (recvmsg_secure and
    > >   recvfrom_secure).
    >
    > i too could use such a hook. the sock_rcv_skb hook is not useful
    > in conjunction with socket level recvmsg hook.  we definitely need a
    > way to to correlate the lower level labelling to the process context.
    > is the inode reference not sufficient from sock_rcv_skb context?
    
    I don't believe it is sufficient to copy the information into the
    socket/inode security structure since we would then need to serialize
    access to that structure to prevent it from becoming overwritten by future
    calls to sock_rcv_skb.
    
    I'm open to alternatives, but could not come up with any on my own.
    
    chris.
    
    _______________________________________________
    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 : Tue Mar 19 2002 - 09:46:43 PST