Permit multiple active LSM modules

The authors of the TOMOYO project want to use multiple active LSM modules and
have posted patches to do this via hash tables in lieu of security pointers in
objects.  I think this is the wrong approach.

Multiple LSM modules are not currently possible as there is only one security
pointer in the cred struct and there is no defined way to chain.  SELinux, for
example, simply assumes that it completely owns the security pointer as
currently only one security module may be in force simultaneously.

This series of patches permits register_security() to accept multiple modules
that require security data attaching to various objects (creds, keys, files,
inodes, superblocks, IPC permissions and messages and sockets).  When it
registers, each module states the amount of security data it requires for each
object.

The security framework aggregates the security data for each object into one
allocation which _it_ makes rather than the LSM.  Where possible, this
allocation is appended to the allocation of the object itself.  The offset of
the security data for each class of objects for an LSM is stored in that LSM's
pointer table, and wrappers are then provided.

These patches theoretically permit multiple LSMs to be selected, but I haven't
tested that as my test machine is only set up for SELinux at this time.  They
do, however, with SELinux alone.

Multiple LSM modules can be requested on the command line by listing them in
order, for example:

	security=selinux,tomoyo

Issues encountered:

 (*) Should smack_file_send_sigiotask() be using tsk->cred or tsk->real_cred
     on the target?

 (*) Which module should get to handle secid/secctx requests?  Currently when
     it comes to retrieving or converting these, then the first module that
     offers the service gets it, and subsequent modules are ignored.

 (*) Should there be a way of marking certain module mixes as not permitted
     (say SELinux and Smack or TOMOYO and AppArmor)?

I'm not sure how feasible mixing multiple LSM modules actually is, but the
TOMOYO people seem to have a use case for it.

---

David Howells (21):
      LSM: Remove the default capability stubs
      LSM: Iterate through multiple LSM modules
      LSM: Rewrite the iterators to use trivial iteration
      LSM: Wrap calls to security module ops so they can be turned into iterators
      LSM: Permit security data on sockets for multiple security modules
      LSM: Wrap accesses to sock::sk_security (SELinux/Smack)
      LSM: Permit security data on IPC perms and messages for multiple security modules
      LSM: Wrap accesses to kern_ipc_perm::security and msg_msg::security (SELinux/Smack)
      LSM: Permit security data on inodes for multiple security modules
      LSM: Wrap accesses to inode::i_security (SELinux/Smack)
      LSM: Permit security data on open files for multiple security modules
      LSM: Wrap accesses to file::f_security (AppArmor/SELinux/Smack)
      LSM: Permit security data on superblocks for multiple security modules
      LSM: Wrap accesses to super_block::s_security (SELinux/Smack)
      LSM: Permit security data on keys for multiple security modules
      LSM: Wrap accesses to key::security (SELinux/Smack)
      LSM: Permit security data on creds for multiple security modules
      LSM: Wrap accesses to cred::security (AppArmor/SELinux/Smack/TOMOYO)
      LSM: Prepare for multiple, simultaneous LSM modules
      TOMOYO: Fix tomoyo_dentry_open() to use the right creds
      LSM: Allocate init_cred at runtime rather than at compile time


 drivers/base/devtmpfs.c               |    4 
 fs/file_table.c                       |   14 
 fs/inode.c                            |    4 
 fs/super.c                            |   14 
 include/linux/cred.h                  |    9 
 include/linux/fs.h                    |   14 
 include/linux/init_task.h             |    4 
 include/linux/ipc.h                   |    4 
 include/linux/key.h                   |    8 
 include/linux/msg.h                   |    2 
 include/linux/security.h              |  409 +++++++++----
 include/linux/xattr.h                 |   18 -
 include/net/sock.h                    |    2 
 init/main.c                           |    2 
 ipc/msg.c                             |    7 
 ipc/msgutil.c                         |    5 
 ipc/sem.c                             |    7 
 ipc/shm.c                             |    7 
 kernel/cred.c                         |  112 ++-
 kernel/exit.c                         |    4 
 net/core/sock.c                       |   10 
 security/Makefile                     |    2 
 security/apparmor/context.c           |   39 -
 security/apparmor/domain.c            |   21 -
 security/apparmor/include/context.h   |   56 +-
 security/apparmor/lsm.c               |  168 ++---
 security/capability.c                 | 1070 ---------------------------------
 security/commoncap.c                  |   36 +
 security/keys/key.c                   |   22 -
 security/security.c                   | 1003 ++++++++++++++++++++++---------
 security/selinux/hooks.c              |  800 ++++++++-----------------
 security/selinux/include/lsm_access.h |  213 +++++++
 security/selinux/include/security.h   |    3 
 security/selinux/include/xfrm.h       |    2 
 security/selinux/netlabel.c           |   13 
 security/selinux/selinuxfs.c          |   52 +-
 security/selinux/ss/services.c        |    1 
 security/selinux/xfrm.c               |   11 
 security/smack/smack.h                |  175 +++++
 security/smack/smack_lsm.c            |  657 ++++++++------------
 security/smack/smackfs.c              |    7 
 security/tomoyo/common.h              |   36 +
 security/tomoyo/domain.c              |    2 
 security/tomoyo/securityfs_if.c       |    2 
 security/tomoyo/tomoyo.c              |   76 +-
 45 files changed, 2286 insertions(+), 2841 deletions(-)
 delete mode 100644 security/capability.c
 create mode 100644 security/selinux/include/lsm_access.h

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html