Thanks for the comments James. See my reply below.
On Wed, 10 Jul 2002, James Morris wrote:
>
> Is this because using the inode security blob wasn't enough?
>
Yes, with multiple connections to a listening socket, we can't reliably
keep the client security info on the listening socket's inode security
structure. The association to the socket structure for the new sock is
made later, so we need to keep the client security info with the sock.
>
> Here is some initial feedback:
>
> - Use kmem_cache_free(sk_cachep, sk) instead of kfree(sk) in sk_alloc().
>
OK, good catch.
>
> - Pass priority arg through to socket_sock_alloc_security().
>
Should we address the other alloc hooks (skb_alloc_security, etc.) then
too?
> - Pointer save not needed in tcp_create_openreq_child().
>
Hmm, can you explain why not? The code in question:
void *sptr = newsk->security;
memcpy(newsk, sk, sizeof(*newsk));
newsk->security = sptr;
newsk->security is set before this code in the sk_alloc() call, and we
need to prevent this pointer from being overwritten with the listening
sock's security pointer.
> - The socket_sock_connect() hook is TCP specific, probably better to call
> it tcp_create_openreq_child().
>
Well, I went back and forth on this. I'm not sure this hook will always
be TCP specific.
> I'm also wondering what effect an sk->security blob might have on the
> rest of the API, e.g:
>
> - Is it useful as an argument elsewhere (as it is with the modified
> unix hook)?
>
I'm not sure what you mean. The unix_stream_connect() hook was modified
to include the new sock structure as a parameter. I think it was an
oversight not to include it originally. However, any hook that is passed a
sock struct can make use of the sock security field.
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:30:46 PDT