On Tue, 9 Jul 2002, Wayne Salamon wrote:
>
>
> I am proposing a set of hooks to allow client security information to be
> reliably associated with a new socket connection. The security structure
> is attached to the sock, and can be used to store information about the
> client when a new connection is created. This information can then be
> propagated to user space via the socket structure.
>
Is this because using the inode security blob wasn't enough?
> SELinux uses these hooks to provide the security ID of the connecting
> client to the server via the extended socket calls. The patch files
> include the necessary SELinux changes.
>
> Comments?
Here is some initial feedback:
- Use kmem_cache_free(sk_cachep, sk) instead of kfree(sk) in sk_alloc().
- Minor nitpick re. standard kernel coding style:
if(something)
should be
if (something)
- Pass priority arg through to socket_sock_alloc_security().
- Pointer save not needed in tcp_create_openreq_child().
- The socket_sock_connect() hook is TCP specific, probably better to call
it tcp_create_openreq_child().
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)?
- Does it makes possible any new, useful hooks?
- Does it allow us to get rid of any hooks?
--
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 : Wed Jul 10 2002 - 04:24:59 PDT