Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: David Howells <dhowells <at> redhat.com>
Subject: [PATCH 00/21] Permit multiple active LSM modules
Newsgroups: gmane.linux.kernel.lsm
Date: Thursday 3rd February 2011 02:09:57 UTC (over 6 years ago)
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
CD: 3ms