mbox series

[00/59] LSM: Module stacking for AppArmor

Message ID 20190409213946.1667-1-casey@schaufler-ca.com (mailing list archive)
Headers show
Series LSM: Module stacking for AppArmor | expand

Message

Casey Schaufler April 9, 2019, 9:38 p.m. UTC
This patchset provides the changes required for
the AppArmor security module to stack safely with
"exclusive" security modules, those being SELinux and
Smack. 

Performance: Using a kernel compile benchmark indicates
a performance impact of 0.15% for a Fedora 29 system
with SELinux. Adding AppArmor has an additional 0.20%
impact. Fedora does not include an AppArmor profile.

A new process attribute identifies which security module
information should be reported by SO_PEERSEC and the
/proc/.../attr/current interface. This is provided by
/proc/.../attr/display. Writing the name of the security
module desired to this interface will set which LSM hooks
will be called for this information. The first security
module providing the hooks will be used by default.

The use of integer based security tokens (secids) is
generally (but not completely) replaced by a structure
lsm_export. The lsm_export structure can contain information
for each of the security modules that export information
outside the LSM layer.

The LSM interfaces that provide "secctx" text strings
have been changed to use a structure "lsm_context"
instead of a pointer/length pair. In some cases the
interfaces used a "char *" pointer and in others a
"void *". This was necessary to ensure that the correct
release mechanism for the text is used. It also makes
many of the interfaces cleaner.

The security module stacking issues around netlabel
not addressed here as they are beyond what is required 
to stack AppArmor with either SELinux or Smack.

git://github.com/cschaufler/lsm-stacking.git#stack-5.1-rc2-apparmor

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
 drivers/android/binder.c                |  25 ++-
 fs/kernfs/dir.c                         |   6 +-
 fs/kernfs/inode.c                       |  31 ++-
 fs/kernfs/kernfs-internal.h             |   3 +-
 fs/nfs/inode.c                          |  13 +-
 fs/nfs/internal.h                       |   8 +-
 fs/nfs/nfs4proc.c                       |  17 +-
 fs/nfs/nfs4xdr.c                        |  16 +-
 fs/nfsd/nfs4proc.c                      |   8 +-
 fs/nfsd/nfs4xdr.c                       |  14 +-
 fs/nfsd/vfs.c                           |   7 +-
 fs/proc/base.c                          |   1 +
 include/linux/cred.h                    |   3 +-
 include/linux/lsm_hooks.h               |  93 ++++----
 include/linux/nfs4.h                    |   8 +-
 include/linux/security.h                | 137 ++++++++----
 include/net/netlabel.h                  |  10 +-
 include/net/scm.h                       |  14 +-
 kernel/audit.c                          |  43 ++--
 kernel/audit.h                          |   9 +-
 kernel/auditfilter.c                    |   6 +-
 kernel/auditsc.c                        |  77 ++++---
 kernel/cred.c                           |  15 +-
 net/ipv4/cipso_ipv4.c                   |  13 +-
 net/ipv4/ip_sockglue.c                  |  12 +-
 net/netfilter/nf_conntrack_netlink.c    |  29 ++-
 net/netfilter/nf_conntrack_standalone.c |  16 +-
 net/netfilter/nfnetlink_queue.c         |  38 ++--
 net/netfilter/nft_meta.c                |  13 +-
 net/netfilter/xt_SECMARK.c              |  14 +-
 net/netlabel/netlabel_kapi.c            |   5 +-
 net/netlabel/netlabel_unlabeled.c       | 101 +++++----
 net/netlabel/netlabel_unlabeled.h       |   2 +-
 net/netlabel/netlabel_user.c            |  13 +-
 net/netlabel/netlabel_user.h            |   2 +-
 net/unix/af_unix.c                      |  11 +-
 security/apparmor/audit.c               |   4 +-
 security/apparmor/include/audit.h       |   2 +-
 security/apparmor/include/net.h         |   6 +-
 security/apparmor/include/secid.h       |   9 +-
 security/apparmor/lsm.c                 |  64 ++----
 security/apparmor/secid.c               |  42 ++--
 security/integrity/ima/ima.h            |  14 +-
 security/integrity/ima/ima_api.c        |   9 +-
 security/integrity/ima/ima_appraise.c   |   6 +-
 security/integrity/ima/ima_main.c       |  34 +--
 security/integrity/ima/ima_policy.c     |  19 +-
 security/security.c                     | 366 ++++++++++++++++++++++++++++----
 security/selinux/hooks.c                | 259 +++++++++++-----------
 security/selinux/include/audit.h        |   5 +-
 security/selinux/include/objsec.h       |  42 +++-
 security/selinux/netlabel.c             |  25 +--
 security/selinux/ss/services.c          |  18 +-
 security/smack/smack.h                  |  18 ++
 security/smack/smack_lsm.c              | 238 +++++++++++----------
 security/smack/smack_netfilter.c        |   8 +-
 security/smack/smackfs.c                |  12 +-
 57 files changed, 1252 insertions(+), 781 deletions(-)

Comments

Stephen Smalley April 10, 2019, 12:52 p.m. UTC | #1
On Tue, Apr 9, 2019 at 5:40 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> This patchset provides the changes required for
> the AppArmor security module to stack safely with
> "exclusive" security modules, those being SELinux and
> Smack.

What's the use case?  Who would use such support?

>
> Performance: Using a kernel compile benchmark indicates
> a performance impact of 0.15% for a Fedora 29 system
> with SELinux. Adding AppArmor has an additional 0.20%
> impact. Fedora does not include an AppArmor profile.
>
> A new process attribute identifies which security module
> information should be reported by SO_PEERSEC and the
> /proc/.../attr/current interface. This is provided by
> /proc/.../attr/display. Writing the name of the security
> module desired to this interface will set which LSM hooks
> will be called for this information. The first security
> module providing the hooks will be used by default.
>
> The use of integer based security tokens (secids) is
> generally (but not completely) replaced by a structure
> lsm_export. The lsm_export structure can contain information
> for each of the security modules that export information
> outside the LSM layer.
>
> The LSM interfaces that provide "secctx" text strings
> have been changed to use a structure "lsm_context"
> instead of a pointer/length pair. In some cases the
> interfaces used a "char *" pointer and in others a
> "void *". This was necessary to ensure that the correct
> release mechanism for the text is used. It also makes
> many of the interfaces cleaner.
>
> The security module stacking issues around netlabel
> not addressed here as they are beyond what is required
> to stack AppArmor with either SELinux or Smack.
>
> git://github.com/cschaufler/lsm-stacking.git#stack-5.1-rc2-apparmor
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
>  drivers/android/binder.c                |  25 ++-
>  fs/kernfs/dir.c                         |   6 +-
>  fs/kernfs/inode.c                       |  31 ++-
>  fs/kernfs/kernfs-internal.h             |   3 +-
>  fs/nfs/inode.c                          |  13 +-
>  fs/nfs/internal.h                       |   8 +-
>  fs/nfs/nfs4proc.c                       |  17 +-
>  fs/nfs/nfs4xdr.c                        |  16 +-
>  fs/nfsd/nfs4proc.c                      |   8 +-
>  fs/nfsd/nfs4xdr.c                       |  14 +-
>  fs/nfsd/vfs.c                           |   7 +-
>  fs/proc/base.c                          |   1 +
>  include/linux/cred.h                    |   3 +-
>  include/linux/lsm_hooks.h               |  93 ++++----
>  include/linux/nfs4.h                    |   8 +-
>  include/linux/security.h                | 137 ++++++++----
>  include/net/netlabel.h                  |  10 +-
>  include/net/scm.h                       |  14 +-
>  kernel/audit.c                          |  43 ++--
>  kernel/audit.h                          |   9 +-
>  kernel/auditfilter.c                    |   6 +-
>  kernel/auditsc.c                        |  77 ++++---
>  kernel/cred.c                           |  15 +-
>  net/ipv4/cipso_ipv4.c                   |  13 +-
>  net/ipv4/ip_sockglue.c                  |  12 +-
>  net/netfilter/nf_conntrack_netlink.c    |  29 ++-
>  net/netfilter/nf_conntrack_standalone.c |  16 +-
>  net/netfilter/nfnetlink_queue.c         |  38 ++--
>  net/netfilter/nft_meta.c                |  13 +-
>  net/netfilter/xt_SECMARK.c              |  14 +-
>  net/netlabel/netlabel_kapi.c            |   5 +-
>  net/netlabel/netlabel_unlabeled.c       | 101 +++++----
>  net/netlabel/netlabel_unlabeled.h       |   2 +-
>  net/netlabel/netlabel_user.c            |  13 +-
>  net/netlabel/netlabel_user.h            |   2 +-
>  net/unix/af_unix.c                      |  11 +-
>  security/apparmor/audit.c               |   4 +-
>  security/apparmor/include/audit.h       |   2 +-
>  security/apparmor/include/net.h         |   6 +-
>  security/apparmor/include/secid.h       |   9 +-
>  security/apparmor/lsm.c                 |  64 ++----
>  security/apparmor/secid.c               |  42 ++--
>  security/integrity/ima/ima.h            |  14 +-
>  security/integrity/ima/ima_api.c        |   9 +-
>  security/integrity/ima/ima_appraise.c   |   6 +-
>  security/integrity/ima/ima_main.c       |  34 +--
>  security/integrity/ima/ima_policy.c     |  19 +-
>  security/security.c                     | 366 ++++++++++++++++++++++++++++----
>  security/selinux/hooks.c                | 259 +++++++++++-----------
>  security/selinux/include/audit.h        |   5 +-
>  security/selinux/include/objsec.h       |  42 +++-
>  security/selinux/netlabel.c             |  25 +--
>  security/selinux/ss/services.c          |  18 +-
>  security/smack/smack.h                  |  18 ++
>  security/smack/smack_lsm.c              | 238 +++++++++++----------
>  security/smack/smack_netfilter.c        |   8 +-
>  security/smack/smackfs.c                |  12 +-
>  57 files changed, 1252 insertions(+), 781 deletions(-)
Casey Schaufler April 10, 2019, 3:36 p.m. UTC | #2
On 4/10/2019 5:52 AM, Stephen Smalley wrote:
> On Tue, Apr 9, 2019 at 5:40 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> This patchset provides the changes required for
>> the AppArmor security module to stack safely with
>> "exclusive" security modules, those being SELinux and
>> Smack.
> What's the use case?  Who would use such support?


A device uses a Smack three domain policy for system
protection. It Uses AppArmor policy to maintain application
isolation.
   
	-------------------------------------------------------------------
	| Smack floor domain                                              |
	-------------------------------------------------------------------
	| Smack System domain                                             |
	-------------------------------------------------------------------
	| Smack User domain                                               |
	| ----------  ----------  ---------  ----------  ----------       |
	| |AppArmor|  |AppArmor|  |AppArmor| |AppArmor|  |AppArmor|       |
	| | Fred   |  | Wilma  |  |Barney  | | Betty  |  | Dino   |       |
	| ----------  ----------  ---------- ----------  ----------       |
	-------------------------------------------------------------------

Each of the security modules is used in the way it was designed. Neither
has to be stretched beyond its original goals. Yes, you can implement the
system using either Smack or AppArmor (or maybe even SELinux) but by using
each for what it is best at you make it much easier.