The below mentioned lines of code is an excerpt from the kernel
source after the LSM patch is applied.
To try and make the question precise i have deleted non-lsm lines
from the code.
1] The /usr/src/linux-2.4/include/security.h defines the
security_operations struct with socket_create field .
2] /usr/src/linux-2.4/net/socket.c has the function sock_create which calls
[ security_ops->socket_create(family, type, protocol); ] to check for
extended LSM security of socket creation
3] /usr/src/linux-2.4/security/selinux/hooks.c has the LSM
implementation of function call
selinux_socket_create (int family, int type, int protocol, struct
socket **res) .
Question 1 :
--------------------
Everytime a user application tries to create the socket the
net/socket.c : sock_create is invoked and this function intern calls
the security_ops->socket_create function for LSM check , Now where
and how does the selinux_socket_create come into picture .I mean how
does it get invoked ?
Question 2 :
------------------
security_ops->socket_create( ) is the hook employed by the LSM framework
selinux_socket_create ( ) is the implementation of the security module
function
Am i right ?
If not where is the function code to the hook call made from socket.c ?
*/usr/src/linux-2.4/include/security.h
* @socket_create:
* Check permissions prior to creating a new socket.
* @family contains the requested protocol family.
* @type contains the requested communications type.
* @protocol contains the requested protocol.
* Return 0 if permission is granted.
* @socket_post_create:
* This hook allows a module to update or allocate a per-socket security
* structure. Note that the security field was not added directly to the
* socket structure, but rather, the socket security information is stored
* in the associated inode. Typically, the inode alloc_security hook will
* allocate and and attach security information to
* sock->inode->i_security. This hook may be used to update the
* sock->inode->i_security field with additional information that wasn't
* available when the inode was allocated.
* @sock contains the newly created socket structure.
* @family contains the requested protocol family.
* @type contains the requested communications type.
* @protocol contains the requested protocol.
* @socket_bind:
struct security_operations {
int (*socket_create) (int family, int type, int protocol);
void (*socket_post_create) (struct socket * sock, int family,
}
********************************************************************************************************
* /usr/src/linux-2.4/net/socket.c
int sock_create(int family, int type, int protocol, struct socket **res)
{
int i;
int err;
struct socket *sock;
err = security_ops->socket_create(family, type, protocol);
if (err)
return err;
return i;
}
********************************************************************************
/* /usr/src/linux-2.4/security/selinux/hooks.c */
static int selinux_socket_create(int family, int type, int protocol)
{
int err;
struct task_security_struct *tsec;
security_id_t tsid;
tsec = current->security;
tsid = extsocket_create(tsec);
err = avc_has_perm(tsec->sid, tsid,
socket_type_to_security_class(family, type),
SOCKET__CREATE);
return err;
}
*******************************************************************************
Thanks
KIng Khan
On Tue, 18 Jan 2005 15:03:13 -0800, Chris Wright <chrisw@private> wrote:
> * Syed Ahemed (kingkhan@private) wrote:
> > Solution 2
> > ---------------
> > a] LSM with SELINUX : what it does that LIDS[with/without LSM ] cant ?
> > Note : I haven't seen a debate LIDS VS SELINUX , maybe they aren't
> > alike at all.But we have a co-existence problem to solve too.
>
> For the purpose of your examples, consider LIDS and SELinux to have very
> similar properties.
>
> > b] Implement my own strncpy or strcpy with better length checking
>
> For user-space buffer overflow? Sure, it's always useful to carefully
> audit that kind of code.
>
> > c] Openwall patch is a part of base kernel will take care of
> > executable stack issue
>
> Base 2.6 has some support for NX stack. Also, you can look at
> exec-shield in Fedora kernels, or the SSP patch to gcc.
>
> Stopping the buffer overflow is fundamentally different from limiting
> that damage domain. Point is...there is no single silver bullet.
> Best solution is to employ best security practices at each relevant
> layer.
>
> thanks,
> -chris
> --
> Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
>
This archive was generated by hypermail 2.1.3 : Tue Jan 18 2005 - 23:48:03 PST