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
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
kingkhan
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. http://immunix.com/~crispin/
> CTO, Immunix http://immunix.com
>
>
This archive was generated by hypermail 2.1.3 : Fri Jan 21 2005 - 08:11:47 PST