[PATCH 00/58] LSM: Module stacking for AppArmor
José Bollo
jobol at nonadev.net
Fri Jun 7 13:03:45 UTC 2019
On Tue, 4 Jun 2019 09:14:42 -0700
Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 6/4/2019 5:29 AM, Stephen Smalley wrote:
> > On 6/2/19 12:50 PM, Casey Schaufler wrote:
> >> 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.
>
> > - 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.
>
> > 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.
>
> > how would it be used,
>
> As mentioned above, Smack for system separation, AppArmor for
> application isolation.
>
> > 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.
>
> > 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!
>
> > 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.
>
> >
> >>
> >> 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.
>
> >
> >> 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 at 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(-)
> >
More information about the Linux-security-module-archive
mailing list