Re: LSM patch for Linux-2.4.20-8

From: Syed Ahemed (kingkhan@private)
Date: Fri Jan 21 2005 - 08:11:08 PST

Could you please answer this question form , This should nail the
issue of understanding LSM finally .Thanks a lot for answering my
questions .

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
Am i right ?
If not where is the function code to the hook call made from socket.c ?

* @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),

       return err;


On Thu, 20 Jan 2005 17:00:21 -0800, Crispin Cowan <crispin@private> wrote:
> Syed Ahemed wrote:
> >I would love to use Linux 2.6 ,but the 2.4 kernel i mentioned is there
> >on our production machine for quite sometime .
> >I intend to convince myself if LSM is the way to go in the long run .
> >The reason i got drawn towards it cos LSM  addressess security beyond
> >the conventional file , process permissions in the linux model.
> >If you could see the other questions i have putforth on the mailing
> >list ,u know what am addressing .
> >
> >
> I have read all of your questions. Not to be overly critical, but many
> of your questions appear to come from flawed assumptions, and I suspect
> that you need to do a lot more reading and learning before you will be
> able to build new technologies that are effective. Which is why I
> suggested working with existing modules for an existing kernel that
> already has LSM in it (2.6) because that is a much easier place to start.
> >Just a thought , Any specific reasons why isn't there a LSM module
> >that takes care of length checking of strings that cause buffer
> >overflow ( hooks for strcpy or memcpy ) .?
> >
> The above proposal is an example of a flawed assumption. It is ambiguous
> whether you meant to protect against strcpy vulnerabilities in the
> kernel or in application programs. If you meant the kernel, then Valdis'
> response is correct: the kernel has to assume that the kernel is
> correct. If you mean applications, then Seth's response is correct:
> strcpy is a *library* call, not a kernel call, and thus the kernel
> cannot mediate it.
> In the latter case, for examples of ways to defend against strcpy flaws,
> read up on user-level defenses against these user level problems, such
> as StackGuard (my own work) that uses the C compiler to embed buffer
> overflow defenses into programs, and libsafe which provides safer
> versions of strcpy and friends to block buffer overflow attacks.
> >  Even 2.6 doesn't address
> >this.
> >Maybe am missing a fundamental point but considering LSM implements
> >OWL patch for non-executable stack that actually is a "consequence" of
> >a buffer overflow attack ,I felt it makes sense to implement.
> >
> >
> As Valdis points out, the OWLSM module does not implement the
> non-executable stack feature, and there is no way that LSM could ever
> let you implement a module that would provide the non-executable stack
> feature. It is outside the scope of LSM's goal. LSM is there to provide
> an API for access control modules.
> Crispin
> --
> Crispin Cowan, Ph.D.
> CTO, Immunix

This archive was generated by hypermail 2.1.3 : Fri Jan 21 2005 - 08:11:47 PST