On Tue, 4 Jun 2019 09:14:42 -0700
Casey Schaufler [off-list ref] wrote:

On 6/4/2019 5:29 AM, Stephen Smalley wrote:

quoted

On 6/2/19 12:50 PM, Casey Schaufler wrote:  

quoted

This patchset provides the changes required for
the AppArmor security module to stack safely with any other.  

Please explain the motivation  

I'll add some explanation for the next revision.
It won't be anything that I haven't posted many times
before, but you're right that it belongs in the log.

quoted

- why do we want to allow AppArmor to stack with other modules,  

First, is there a reason not to? Sure, you can confuse
administrators by implementing complex security policies,
but there are lots of ways to do that already.

AppArmor provides a different security model than SELinux,
TOMOYO or Smack. Smack is better at system component
separation, while AppArmor is better at application isolation.
It's a win to use each to its strength rather than trying to
stretch either to the edge of what it can do.

quoted

who would use it,  

Hi all,

I would like to expose a potential use of interest for me: being able
to have containers running Smack on Ubuntu or Fedora platforms.

But it could also be interesting for running a container having fedora
on ubuntu or suse or the opposite.

How it will work? Will it work? Ask Casey.

just my 2 pennies
José Bollo

Can't name names, but there have been multiple requests.

quoted

how would it be used,  

As mentioned above, Smack for system separation, AppArmor for
application isolation.

quoted

what does it provide that isn't already possible in the absence of
it.  

It's not necessary that something be impossible to do any
other way. The question should be whether this provides for
a better way to achieve the goals, and this does that.
If I tried the come up with something that's impossible I
would expect the usual "you can do that with SELinux policy"
argument. We know we can do things. We want to have the tools
to do them better.

quoted

Also, Ubuntu fully upstreamed all of their changes to AppArmor,
would this still suffice to enable stacking of AppArmor or do they
rely on hooks that are not handled here?  

Some amount of merging will likely be required. But that's
always going to be true with parallel development tracks.
That's why we have git!

quoted

Please explain the cost of the change - what do we pay in terms of
memory, runtime, or other overheads in order to support this
change?  

Do you have particular benchmarks you want to see?
When I've supplied numbers in the past they have not
been remarked on.

quoted

quoted

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.  

Doesn't this effectively undo making the hooks read-only after
init, at least for the subset involved?  What are the security
implications thereof?  

Any mechanism, be it a separate set of hooks, a name used to
do list look ups, or an sophisticated hash scheme will have that
impact for the processes that use it. This scheme has the best
performance profile of the mechanisms I experimented with and
avoids all sorts of special cases.

quoted

quoted

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.

https://github.com/cschaufler/lsm-stacking.git#stack-5.2-v1-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               |  91 +++++----
  include/linux/nfs4.h                    |   8 +-
  include/linux/security.h                | 133 +++++++++----
  include/net/af_unix.h                   |   2 +-
  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                      |   6 +-
  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                     | 338
+++++++++++++++++++++++++++-----
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 +- 58 files
changed, 1217 insertions(+), 779 deletions(-)