* [BK PATCH] LSM changes for 2.5.40 @ 2002-10-08 23:05 Greg KH 2002-10-08 23:05 ` [PATCH] " Greg KH 2002-10-08 23:07 ` [BK PATCH] LSM changes for 2.5.40 Greg KH 0 siblings, 2 replies; 5+ messages in thread From: Greg KH @ 2002-10-08 23:05 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel, linux-security-module Hi, Here are some patches against the latest 2.5 BK tree that add some further LSM hooks and documenation to the tree. There is also one minor change to fs/inode.c to allow security modules to know more information about newly created inodes. Please pull from bk://lsm.bkbits.net/linus-2.5 thanks, greg k-h Documentation/DocBook/Makefile | 2 Documentation/DocBook/kernel-api.tmpl | 5 Documentation/DocBook/lsm.tmpl | 285 ++++++++++++++++++++++++++++++++++ fs/inode.c | 16 - include/linux/ipc.h | 1 include/linux/security.h | 55 ++++++ ipc/msg.c | 11 + ipc/sem.c | 11 + ipc/shm.c | 10 + ipc/util.c | 3 security/capability.c | 46 +++++ security/dummy.c | 47 +++++ 12 files changed, 482 insertions(+), 10 deletions(-) ----- ChangeSet@1.707, 2002-10-08 14:53:21-07:00, chris@wirex.com [PATCH] LSM: move the inode_alloc_security hook. This moves the inode_alloc_security() hook so that we have all of the inode information at the moment of the hook. fs/inode.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) ------ ChangeSet@1.706, 2002-10-08 14:48:44-07:00, greg@kroah.com LSM: added lsm documentation to the tree. Documentation/DocBook/Makefile | 2 Documentation/DocBook/kernel-api.tmpl | 5 Documentation/DocBook/lsm.tmpl | 285 ++++++++++++++++++++++++++++++++++ 3 files changed, 291 insertions(+), 1 deletion(-) ------ ChangeSet@1.705, 2002-10-08 14:10:38-07:00, sds@tislabs.com [PATCH] Base set of LSM hooks for SysV IPC The patch below adds the base set of LSM hooks for System V IPC to the 2.5.41 kernel. These hooks permit a security module to label semaphore sets, message queues, and shared memory segments and to perform security checks on these objects that parallel the existing IPC access checks. Additional LSM hooks for labeling and controlling individual messages sent on a single message queue and for providing fine-grained distinctions among IPC operations will be submitted separately after this base set of LSM IPC hooks has been accepted. include/linux/ipc.h | 1 include/linux/security.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++ ipc/msg.c | 11 +++++++++ ipc/sem.c | 11 +++++++++ ipc/shm.c | 10 ++++++++ ipc/util.c | 3 +- security/capability.c | 46 +++++++++++++++++++++++++++++++++++++++ security/dummy.c | 47 ++++++++++++++++++++++++++++++++++++++++ 8 files changed, 183 insertions(+), 1 deletion(-) ------ ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] LSM changes for 2.5.40 2002-10-08 23:05 [BK PATCH] LSM changes for 2.5.40 Greg KH @ 2002-10-08 23:05 ` Greg KH 2002-10-08 23:06 ` Greg KH 2002-10-08 23:07 ` [BK PATCH] LSM changes for 2.5.40 Greg KH 1 sibling, 1 reply; 5+ messages in thread From: Greg KH @ 2002-10-08 23:05 UTC (permalink / raw) To: linux-kernel, linux-security-module # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.704 -> 1.705 # include/linux/ipc.h 1.1 -> 1.2 # ipc/msg.c 1.6 -> 1.7 # include/linux/security.h 1.3 -> 1.4 # security/dummy.c 1.6 -> 1.7 # security/capability.c 1.5 -> 1.6 # ipc/sem.c 1.11 -> 1.12 # ipc/util.c 1.5 -> 1.6 # ipc/shm.c 1.17 -> 1.18 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/08 sds@tislabs.com 1.705 # [PATCH] Base set of LSM hooks for SysV IPC # # The patch below adds the base set of LSM hooks for System V IPC to the # 2.5.41 kernel. These hooks permit a security module to label # semaphore sets, message queues, and shared memory segments and to # perform security checks on these objects that parallel the existing # IPC access checks. Additional LSM hooks for labeling and controlling # individual messages sent on a single message queue and for providing # fine-grained distinctions among IPC operations will be submitted # separately after this base set of LSM IPC hooks has been accepted. # -------------------------------------------- # diff -Nru a/include/linux/ipc.h b/include/linux/ipc.h --- a/include/linux/ipc.h Tue Oct 8 15:51:15 2002 +++ b/include/linux/ipc.h Tue Oct 8 15:51:15 2002 @@ -63,6 +63,7 @@ gid_t cgid; mode_t mode; unsigned long seq; + void *security; }; #endif /* __KERNEL__ */ diff -Nru a/include/linux/security.h b/include/linux/security.h --- a/include/linux/security.h Tue Oct 8 15:51:15 2002 +++ b/include/linux/security.h Tue Oct 8 15:51:15 2002 @@ -572,6 +572,50 @@ * is being reparented to the init task. * @p contains the task_struct for the kernel thread. * + * Security hooks affecting all System V IPC operations. + * + * @ipc_permission: + * Check permissions for access to IPC + * @ipcp contains the kernel IPC permission structure + * @flag contains the desired (requested) permission set + * Return 0 if permission is granted. + * + * Security hooks for System V IPC Message Queues + * + * @msg_queue_alloc_security: + * Allocate and attach a security structure to the + * msq->q_perm.security field. The security field is initialized to + * NULL when the structure is first created. + * @msq contains the message queue structure to be modified. + * Return 0 if operation was successful and permission is granted. + * @msg_queue_free_security: + * Deallocate security structure for this message queue. + * @msq contains the message queue structure to be modified. + * + * Security hooks for System V Shared Memory Segments + * + * @shm_alloc_security: + * Allocate and attach a security structure to the shp->shm_perm.security + * field. The security field is initialized to NULL when the structure is + * first created. + * @shp contains the shared memory structure to be modified. + * Return 0 if operation was successful and permission is granted. + * @shm_free_security: + * Deallocate the security struct for this memory segment. + * @shp contains the shared memory structure to be modified. + * + * Security hooks for System V Semaphores + * + * @sem_alloc_security: + * Allocate and attach a security structure to the sma->sem_perm.security + * field. The security field is initialized to NULL when the structure is + * first created. + * @sma contains the semaphore structure + * Return 0 if operation was successful and permission is granted. + * @sem_free_security: + * deallocate security struct for this semaphore + * @sma contains the semaphore structure. + * * @ptrace: * Check permission before allowing the @parent process to trace the * @child process. @@ -785,6 +829,17 @@ unsigned long arg5); void (*task_kmod_set_label) (void); void (*task_reparent_to_init) (struct task_struct * p); + + int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag); + + int (*msg_queue_alloc_security) (struct msg_queue * msq); + void (*msg_queue_free_security) (struct msg_queue * msq); + + int (*shm_alloc_security) (struct shmid_kernel * shp); + void (*shm_free_security) (struct shmid_kernel * shp); + + int (*sem_alloc_security) (struct sem_array * sma); + void (*sem_free_security) (struct sem_array * sma); /* allow module stacking */ int (*register_security) (const char *name, diff -Nru a/ipc/msg.c b/ipc/msg.c --- a/ipc/msg.c Tue Oct 8 15:51:15 2002 +++ b/ipc/msg.c Tue Oct 8 15:51:15 2002 @@ -22,6 +22,7 @@ #include <linux/init.h> #include <linux/proc_fs.h> #include <linux/list.h> +#include <linux/security.h> #include <asm/uaccess.h> #include "util.h" @@ -89,6 +90,7 @@ static int newque (key_t key, int msgflg) { int id; + int retval; struct msg_queue *msq; msq = (struct msg_queue *) kmalloc (sizeof (*msq), GFP_KERNEL); @@ -98,8 +100,16 @@ msq->q_perm.mode = (msgflg & S_IRWXUGO); msq->q_perm.key = key; + msq->q_perm.security = NULL; + retval = security_ops->msg_queue_alloc_security(msq); + if (retval) { + kfree(msq); + return retval; + } + id = ipc_addid(&msg_ids, &msq->q_perm, msg_ctlmni); if(id == -1) { + security_ops->msg_queue_free_security(msq); kfree(msq); return -ENOSPC; } @@ -271,6 +281,7 @@ free_msg(msg); } atomic_sub(msq->q_cbytes, &msg_bytes); + security_ops->msg_queue_free_security(msq); kfree(msq); } diff -Nru a/ipc/sem.c b/ipc/sem.c --- a/ipc/sem.c Tue Oct 8 15:51:15 2002 +++ b/ipc/sem.c Tue Oct 8 15:51:15 2002 @@ -63,6 +63,7 @@ #include <linux/init.h> #include <linux/proc_fs.h> #include <linux/smp_lock.h> +#include <linux/security.h> #include <asm/uaccess.h> #include "util.h" @@ -115,6 +116,7 @@ static int newary (key_t key, int nsems, int semflg) { int id; + int retval; struct sem_array *sma; int size; @@ -133,8 +135,16 @@ sma->sem_perm.mode = (semflg & S_IRWXUGO); sma->sem_perm.key = key; + sma->sem_perm.security = NULL; + retval = security_ops->sem_alloc_security(sma); + if (retval) { + ipc_free(sma, size); + return retval; + } + id = ipc_addid(&sem_ids, &sma->sem_perm, sc_semmni); if(id == -1) { + security_ops->sem_free_security(sma); ipc_free(sma, size); return -ENOSPC; } @@ -417,6 +427,7 @@ used_sems -= sma->sem_nsems; size = sizeof (*sma) + sma->sem_nsems * sizeof (struct sem); + security_ops->sem_free_security(sma); ipc_free(sma, size); } diff -Nru a/ipc/shm.c b/ipc/shm.c --- a/ipc/shm.c Tue Oct 8 15:51:15 2002 +++ b/ipc/shm.c Tue Oct 8 15:51:15 2002 @@ -24,6 +24,7 @@ #include <linux/mman.h> #include <linux/proc_fs.h> #include <linux/shmem_fs.h> +#include <linux/security.h> #include <asm/uaccess.h> #include "util.h" @@ -115,6 +116,7 @@ shm_unlock(shp->id); shmem_lock(shp->shm_file, 0); fput (shp->shm_file); + security_ops->shm_free_security(shp); kfree (shp); } @@ -185,6 +187,13 @@ shp->shm_perm.key = key; shp->shm_flags = (shmflg & S_IRWXUGO); + shp->shm_perm.security = NULL; + error = security_ops->shm_alloc_security(shp); + if (error) { + kfree(shp); + return error; + } + sprintf (name, "SYSV%08x", key); file = shmem_file_setup(name, size, VM_ACCOUNT); error = PTR_ERR(file); @@ -213,6 +222,7 @@ no_id: fput(file); no_file: + security_ops->shm_free_security(shp); kfree(shp); return error; } diff -Nru a/ipc/util.c b/ipc/util.c --- a/ipc/util.c Tue Oct 8 15:51:15 2002 +++ b/ipc/util.c Tue Oct 8 15:51:15 2002 @@ -19,6 +19,7 @@ #include <linux/vmalloc.h> #include <linux/slab.h> #include <linux/highuid.h> +#include <linux/security.h> #if defined(CONFIG_SYSVIPC) @@ -263,7 +264,7 @@ !capable(CAP_IPC_OWNER)) return -1; - return 0; + return security_ops->ipc_permission(ipcp, flag); } /* diff -Nru a/security/capability.c b/security/capability.c --- a/security/capability.c Tue Oct 8 15:51:15 2002 +++ b/security/capability.c Tue Oct 8 15:51:15 2002 @@ -679,6 +679,41 @@ return; } +static int cap_ipc_permission (struct kern_ipc_perm *ipcp, short flag) +{ + return 0; +} + +static int cap_msg_queue_alloc_security (struct msg_queue *msq) +{ + return 0; +} + +static void cap_msg_queue_free_security (struct msg_queue *msq) +{ + return; +} + +static int cap_shm_alloc_security (struct shmid_kernel *shp) +{ + return 0; +} + +static void cap_shm_free_security (struct shmid_kernel *shp) +{ + return; +} + +static int cap_sem_alloc_security (struct sem_array *sma) +{ + return 0; +} + +static void cap_sem_free_security (struct sem_array *sma) +{ + return; +} + static int cap_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -781,6 +816,17 @@ .task_prctl = cap_task_prctl, .task_kmod_set_label = cap_task_kmod_set_label, .task_reparent_to_init = cap_task_reparent_to_init, + + .ipc_permission = cap_ipc_permission, + + .msg_queue_alloc_security = cap_msg_queue_alloc_security, + .msg_queue_free_security = cap_msg_queue_free_security, + + .shm_alloc_security = cap_shm_alloc_security, + .shm_free_security = cap_shm_free_security, + + .sem_alloc_security = cap_sem_alloc_security, + .sem_free_security = cap_sem_free_security, .register_security = cap_register, .unregister_security = cap_unregister, diff -Nru a/security/dummy.c b/security/dummy.c --- a/security/dummy.c Tue Oct 8 15:51:15 2002 +++ b/security/dummy.c Tue Oct 8 15:51:15 2002 @@ -493,6 +493,42 @@ return; } +static int dummy_ipc_permission (struct kern_ipc_perm *ipcp, short flag) +{ + return 0; +} + + +static int dummy_msg_queue_alloc_security (struct msg_queue *msq) +{ + return 0; +} + +static void dummy_msg_queue_free_security (struct msg_queue *msq) +{ + return; +} + +static int dummy_shm_alloc_security (struct shmid_kernel *shp) +{ + return 0; +} + +static void dummy_shm_free_security (struct shmid_kernel *shp) +{ + return; +} + +static int dummy_sem_alloc_security (struct sem_array *sma) +{ + return 0; +} + +static void dummy_sem_free_security (struct sem_array *sma) +{ + return; +} + static int dummy_register (const char *name, struct security_operations *ops) { return -EINVAL; @@ -595,6 +631,17 @@ .task_prctl = dummy_task_prctl, .task_kmod_set_label = dummy_task_kmod_set_label, .task_reparent_to_init = dummy_task_reparent_to_init, + + .ipc_permission = dummy_ipc_permission, + + .msg_queue_alloc_security = dummy_msg_queue_alloc_security, + .msg_queue_free_security = dummy_msg_queue_free_security, + + .shm_alloc_security = dummy_shm_alloc_security, + .shm_free_security = dummy_shm_free_security, + + .sem_alloc_security = dummy_sem_alloc_security, + .sem_free_security = dummy_sem_free_security, .register_security = dummy_register, .unregister_security = dummy_unregister, ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] LSM changes for 2.5.40 2002-10-08 23:05 ` [PATCH] " Greg KH @ 2002-10-08 23:06 ` Greg KH 2002-10-08 23:07 ` [PATCH] LSM changes for 2.5.41 Greg KH 0 siblings, 1 reply; 5+ messages in thread From: Greg KH @ 2002-10-08 23:06 UTC (permalink / raw) To: linux-kernel, linux-security-module # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.705 -> 1.706 # Documentation/DocBook/kernel-api.tmpl 1.19 -> 1.20 # Documentation/DocBook/Makefile 1.32 -> 1.33 # (new) -> 1.1 Documentation/DocBook/lsm.tmpl # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/08 greg@kroah.com 1.706 # LSM: added lsm documentation to the tree. # -------------------------------------------- # diff -Nru a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile --- a/Documentation/DocBook/Makefile Tue Oct 8 15:51:08 2002 +++ b/Documentation/DocBook/Makefile Tue Oct 8 15:51:08 2002 @@ -11,7 +11,7 @@ kernel-locking.sgml via-audio.sgml mousedrivers.sgml \ deviceiobook.sgml procfs-guide.sgml tulip-user.sgml \ writing_usb_driver.sgml scsidrivers.sgml sis900.sgml \ - kernel-api.sgml journal-api.sgml + kernel-api.sgml journal-api.sgml lsm.sgml JBDSOURCES := $(TOPDIR)/include/linux/jbd.h \ $(TOPDIR)/fs/jbd/journal.c \ diff -Nru a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl --- a/Documentation/DocBook/kernel-api.tmpl Tue Oct 8 15:51:08 2002 +++ b/Documentation/DocBook/kernel-api.tmpl Tue Oct 8 15:51:08 2002 @@ -185,6 +185,11 @@ !Efs/devfs/base.c </chapter> + <chapter id="security"> + <title>Security Framework</title> +!Esecurity/security.c + </chapter> + <chapter id="pmfuncs"> <title>Power Management</title> !Ekernel/pm.c diff -Nru a/Documentation/DocBook/lsm.tmpl b/Documentation/DocBook/lsm.tmpl --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/Documentation/DocBook/lsm.tmpl Tue Oct 8 15:51:09 2002 @@ -0,0 +1,285 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN"[]> +<article class="whitepaper" id="LinuxSecurityModule" lang="en"> + <artheader> + <title>Linux Security Modules: General Security Hooks for Linux</title> + <authorgroup> + <author> + <firstname>Stephen</firstname> + <surname>Smalley</surname> + <affiliation> + <orgname>NAI Labs</orgname> + <address><email>ssmalley@nai.com</email></address> + </affiliation> + </author> + <author> + <firstname>Timothy</firstname> + <surname>Fraser</surname> + <affiliation> + <orgname>NAI Labs</orgname> + <address><email>tfraser@nai.com</email></address> + </affiliation> + </author> + <author> + <firstname>Chris</firstname> + <surname>Vance</surname> + <affiliation> + <orgname>NAI Labs</orgname> + <address><email>cvance@nai.com</email></address> + </affiliation> + </author> + </authorgroup + </artheader> + +<sect1><title>Introduction</title> + +<para> +In March 2001, the National Security Agency (NSA) gave a presentation +about Security-Enhanced Linux (SELinux) at the 2.5 Linux Kernel +Summit. SELinux is an implementation of flexible and fine-grained +nondiscretionary access controls in the Linux kernel, originally +implemented as its own particular kernel patch. Several other +security projects (e.g. RSBAC, Medusa) have also developed flexible +access control architectures for the Linux kernel, and various +projects have developed particular access control models for Linux +(e.g. LIDS, DTE, SubDomain). Each project has developed and +maintained its own kernel patch to support its security needs. +</para> + +<para> +In response to the NSA presentation, Linus Torvalds made a set of +remarks that described a security framework he would be willing to +consider for inclusion in the mainstream Linux kernel. He described a +general framework that would provide a set of security hooks to +control operations on kernel objects and a set of opaque security +fields in kernel data structures for maintaining security attributes. +This framework could then be used by loadable kernel modules to +implement any desired model of security. Linus also suggested the +possibility of migrating the Linux capabilities code into such a +module. +</para> + +<para> +The Linux Security Modules (LSM) project was started by WireX to +develop such a framework. LSM is a joint development effort by +several security projects, including Immunix, SELinux, SGI and Janus, +and several individuals, including Greg Kroah-Hartman and James +Morris, to develop a Linux kernel patch that implements this +framework. The patch is currently tracking the 2.4 series and is +targeted for integration into the 2.5 development series. This +technical report provides an overview of the framework and the example +capabilities security module provided by the LSM kernel patch. +</para> + +</sect1> + +<sect1 id="framework"><title>LSM Framework</title> + +<para> +The LSM kernel patch provides a general kernel framework to support +security modules. In particular, the LSM framework is primarily +focused on supporting access control modules, although future +development is likely to address other security needs such as +auditing. By itself, the framework does not provide any additional +security; it merely provides the infrastructure to support security +modules. The LSM kernel patch also moves most of the capabilities +logic into an optional security module, with the system defaulting +to the traditional superuser logic. This capabilities module +is discussed further in <XRef LinkEnd="cap">. +</para> + +<para> +The LSM kernel patch adds security fields to kernel data structures +and inserts calls to hook functions at critical points in the kernel +code to manage the security fields and to perform access control. It +also adds functions for registering and unregistering security +modules, and adds a general <function>security</function> system call +to support new system calls for security-aware applications. +</para> + +<para> +The LSM security fields are simply <type>void*</type> pointers. For +process and program execution security information, security fields +were added to <structname>struct task_struct</structname> and +<structname>struct linux_binprm</structname>. For filesystem security +information, a security field was added to +<structname>struct super_block</structname>. For pipe, file, and socket +security information, security fields were added to +<structname>struct inode</structname> and +<structname>struct file</structname>. For packet and network device security +information, security fields were added to +<structname>struct sk_buff</structname> and +<structname>struct net_device</structname>. For System V IPC security +information, security fields were added to +<structname>struct kern_ipc_perm</structname> and +<structname>struct msg_msg</structname>; additionally, the definitions +for <structname>struct msg_msg</structname>, <structname>struct +msg_queue</structname>, and <structname>struct +shmid_kernel</structname> were moved to header files +(<filename>include/linux/msg.h</filename> and +<filename>include/linux/shm.h</filename> as appropriate) to allow +the security modules to use these definitions. +</para> + +<para> +Each LSM hook is a function pointer in a global table, +security_ops. This table is a +<structname>security_operations</structname> structure as defined by +<filename>include/linux/security.h</filename>. Detailed documentation +for each hook is included in this header file. At present, this +structure consists of a collection of substructures that group related +hooks based on the kernel object (e.g. task, inode, file, sk_buff, +etc) as well as some top-level hook function pointers for system +operations. This structure is likely to be flattened in the future +for performance. The placement of the hook calls in the kernel code +is described by the "called:" lines in the per-hook documentation in +the header file. The hook calls can also be easily found in the +kernel code by looking for the string "security_ops->". + +</para> + +<para> +Linus mentioned per-process security hooks in his original remarks as a +possible alternative to global security hooks. However, if LSM were +to start from the perspective of per-process hooks, then the base +framework would have to deal with how to handle operations that +involve multiple processes (e.g. kill), since each process might have +its own hook for controlling the operation. This would require a +general mechanism for composing hooks in the base framework. +Additionally, LSM would still need global hooks for operations that +have no process context (e.g. network input operations). +Consequently, LSM provides global security hooks, but a security +module is free to implement per-process hooks (where that makes sense) +by storing a security_ops table in each process' security field and +then invoking these per-process hooks from the global hooks. +The problem of composition is thus deferred to the module. +</para> + +<para> +The global security_ops table is initialized to a set of hook +functions provided by a dummy security module that provides +traditional superuser logic. A <function>register_security</function> +function (in <filename>security/security.c</filename>) is provided to +allow a security module to set security_ops to refer to its own hook +functions, and an <function>unregister_security</function> function is +provided to revert security_ops to the dummy module hooks. This +mechanism is used to set the primary security module, which is +responsible for making the final decision for each hook. +</para> + +<para> +LSM also provides a simple mechanism for stacking additional security +modules with the primary security module. It defines +<function>register_security</function> and +<function>unregister_security</function> hooks in the +<structname>security_operations</structname> structure and provides +<function>mod_reg_security</function> and +<function>mod_unreg_security</function> functions that invoke these +hooks after performing some sanity checking. A security module can +call these functions in order to stack with other modules. However, +the actual details of how this stacking is handled are deferred to the +module, which can implement these hooks in any way it wishes +(including always returning an error if it does not wish to support +stacking). In this manner, LSM again defers the problem of +composition to the module. +</para> + +<para> +Although the LSM hooks are organized into substructures based on +kernel object, all of the hooks can be viewed as falling into two +major categories: hooks that are used to manage the security fields +and hooks that are used to perform access control. Examples of the +first category of hooks include the +<function>alloc_security</function> and +<function>free_security</function> hooks defined for each kernel data +structure that has a security field. These hooks are used to allocate +and free security structures for kernel objects. The first category +of hooks also includes hooks that set information in the security +field after allocation, such as the <function>post_lookup</function> +hook in <structname>struct inode_security_ops</structname>. This hook +is used to set security information for inodes after successful lookup +operations. An example of the second category of hooks is the +<function>permission</function> hook in +<structname>struct inode_security_ops</structname>. This hook checks +permission when accessing an inode. +</para> + +<para> +LSM adds a general <function>security</function> system call that +simply invokes the <function>sys_security</function> hook. This +system call and hook permits security modules to implement new system +calls for security-aware applications. The interface is similar to +socketcall, but also has an <parameter>id</parameter> to help identify +the security module whose call is being invoked. +To eliminate the need for a central registry of ids, +the recommended convention for creating the hexadecimal id value is: +<programlisting> +<![CDATA[ + echo "Name_of_module" | md5sum | cut -c -8 +]]> +</programlisting> +C code will need to prefix this result with ``0x''. +For example, the id for ``SGI Trusted Linux'' could be used in C as: +<programlisting> +<![CDATA[ + #define SYS_SECURITY_MODID 0xc4c7be22 +]]> +</programlisting> +</para> + +</sect1> + +<sect1 id="cap"><title>LSM Capabilities Module</title> + +<para> +The LSM kernel patch moves most of the existing POSIX.1e capabilities +logic into an optional security module stored in the file +<filename>security/capability.c</filename>. This change allows +users who do not want to use capabilities to omit this code entirely +from their kernel, instead using the dummy module for traditional +superuser logic or any other module that they desire. This change +also allows the developers of the capabilities logic to maintain and +enhance their code more freely, without needing to integrate patches +back into the base kernel. +</para> + +<para> +In addition to moving the capabilities logic, the LSM kernel patch +could move the capability-related fields from the kernel data +structures into the new security fields managed by the security +modules. However, at present, the LSM kernel patch leaves the +capability fields in the kernel data structures. In his original +remarks, Linus suggested that this might be preferable so that other +security modules can be easily stacked with the capabilities module +without needing to chain multiple security structures on the security field. +It also avoids imposing extra overhead on the capabilities module +to manage the security fields. However, the LSM framework could +certainly support such a move if it is determined to be desirable, +with only a few additional changes described below. +</para> + +<para> +At present, the capabilities logic for computing process capabilities +on <function>execve</function> and <function>set*uid</function>, +checking capabilities for a particular process, saving and checking +capabilities for netlink messages, and handling the +<function>capget</function> and <function>capset</function> system +calls have been moved into the capabilities module. There are still a +few locations in the base kernel where capability-related fields are +directly examined or modified, but the current version of the LSM +patch does allow a security module to completely replace the +assignment and testing of capabilities. These few locations would +need to be changed if the capability-related fields were moved into +the security field. The following is a list of known locations that +still perform such direct examination or modification of +capability-related fields: +<itemizedlist> +<listitem><para><filename>fs/open.c</filename>:<function>sys_access</function></para></listitem> +<listitem><para><filename>fs/lockd/host.c</filename>:<function>nlm_bind_host</function></para></listitem> +<listitem><para><filename>fs/nfsd/auth.c</filename>:<function>nfsd_setuser</function></para></listitem> +<listitem><para><filename>fs/proc/array.c</filename>:<function>task_cap</function></para></listitem> +</itemizedlist> +</para> + +</sect1> + +</article> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] LSM changes for 2.5.41 2002-10-08 23:06 ` Greg KH @ 2002-10-08 23:07 ` Greg KH 0 siblings, 0 replies; 5+ messages in thread From: Greg KH @ 2002-10-08 23:07 UTC (permalink / raw) To: linux-kernel, linux-security-module # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.706 -> 1.707 # fs/inode.c 1.70 -> 1.71 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 02/10/08 chris@wirex.com 1.707 # [PATCH] LSM: move the inode_alloc_security hook. # # This moves the inode_alloc_security() hook so that we have all of the # inode information at the moment of the hook. # -------------------------------------------- # diff -Nru a/fs/inode.c b/fs/inode.c --- a/fs/inode.c Tue Oct 8 15:51:04 2002 +++ b/fs/inode.c Tue Oct 8 15:51:04 2002 @@ -101,14 +101,6 @@ if (inode) { struct address_space * const mapping = &inode->i_data; - inode->i_security = NULL; - if (security_ops->inode_alloc_security(inode)) { - if (inode->i_sb->s_op->destroy_inode) - inode->i_sb->s_op->destroy_inode(inode); - else - kmem_cache_free(inode_cachep, (inode)); - return NULL; - } inode->i_sb = sb; inode->i_dev = sb->s_dev; inode->i_blkbits = sb->s_blocksize_bits; @@ -127,6 +119,14 @@ inode->i_pipe = NULL; inode->i_bdev = NULL; inode->i_cdev = NULL; + inode->i_security = NULL; + if (security_ops->inode_alloc_security(inode)) { + if (inode->i_sb->s_op->destroy_inode) + inode->i_sb->s_op->destroy_inode(inode); + else + kmem_cache_free(inode_cachep, (inode)); + return NULL; + } mapping->a_ops = &empty_aops; mapping->host = inode; ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BK PATCH] LSM changes for 2.5.40 2002-10-08 23:05 [BK PATCH] LSM changes for 2.5.40 Greg KH 2002-10-08 23:05 ` [PATCH] " Greg KH @ 2002-10-08 23:07 ` Greg KH 1 sibling, 0 replies; 5+ messages in thread From: Greg KH @ 2002-10-08 23:07 UTC (permalink / raw) To: torvalds; +Cc: linux-kernel, linux-security-module Oops, wrong Subject: these are against 2.5.41 + latest bk tree. Sorry for any confusion. greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-10-08 23:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-10-08 23:05 [BK PATCH] LSM changes for 2.5.40 Greg KH 2002-10-08 23:05 ` [PATCH] " Greg KH 2002-10-08 23:06 ` Greg KH 2002-10-08 23:07 ` [PATCH] LSM changes for 2.5.41 Greg KH 2002-10-08 23:07 ` [BK PATCH] LSM changes for 2.5.40 Greg KH
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).