[PATCH 00/90] LSM: Module stacking for all
Stephen Smalley
sds at tycho.nsa.gov
Mon Apr 22 12:46:32 UTC 2019
On 4/21/19 1:31 PM, Casey Schaufler wrote:
> On 4/19/2019 8:27 AM, Stephen Smalley wrote:
>> On 4/18/19 8:44 PM, Casey Schaufler wrote:
>>> This patchset provides the changes required for
>>> the any security module to stack safely with any other.
>>>
>>> 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.
>>>
>>> Security modules that use Netlabel must agree on the
>>> labels to be used on outgoing packets. If the modules
>>> do not agree on the label option to be used the operation
>>> will fail.
>>>
>>> Netfilter secmarks are restricted to a single security
>>> module. The first module using the facility will "own"
>>> the secmarks.
>>
>> Is it expected that enabling all security modules with this change
>> will yield permission denials on packet send/receive (e.g. sendmsg()
>> fails with permission denied), even without any configuration of
>> NetLabel or SECMARK? That's what I see.
>
> Yes.
>
> Smack is much more aggressive about using labeled networking
> than SELinux. Smack tells Netlabel to label networks, whereas
> SELinux expects them to be unlabeled. Smack has the concept of
> an "ambient" label, which is applied to unlabeled packets, and
> for which packets are sent unlabeled. SELinux only uses netlabel
> for the MLS component, whereas Smack uses it for the entire
> label. In short, it's amazing if there's a case where they do
> agree.
>
> You can make the default configuration work better by specifying
> that the Smack "floor" label be treated more like the unconfined_t.
>
> # echo _ 0 0 0 > /sys/fs/smackfs/cipso2
> # echo NotFloor > /sys/fs/smackfs/ambient
>
> Will result in a situation where the two MAC systems will agree
> much more often.
Not sure that should be required given that SELinux doesn't enable
labeled networking at all by default, so there is no real conflict
until/unless someone configures labeled networking for SELinux. I'll
defer to Paul on that question.
Given this restriction, to what extent have you tested Smack+SELinux
together and what worked and didn't work? Everything except for
networking-related tests?
>
>
>>
>>>
>>> git://github.com/cschaufler/lsm-stacking.git#stack-5.1-v2-full
>>>
>>> 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 | 119 +++---
>>> include/linux/nfs4.h | 8 +-
>>> include/linux/security.h | 159 ++++++--
>>> include/net/af_unix.h | 2 +-
>>> include/net/netlabel.h | 18 +-
>>> 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 | 14 +-
>>> net/netfilter/nf_conntrack_netlink.c | 29 +-
>>> net/netfilter/nf_conntrack_standalone.c | 16 +-
>>> net/netfilter/nfnetlink_queue.c | 35 +-
>>> net/netfilter/nft_meta.c | 8 +-
>>> net/netfilter/xt_SECMARK.c | 9 +-
>>> net/netlabel/netlabel_kapi.c | 125 ++++--
>>> 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 | 653
>>> +++++++++++++++++++++++++++-----
>>> security/selinux/hooks.c | 310 +++++++--------
>>> security/selinux/include/audit.h | 5 +-
>>> security/selinux/include/netlabel.h | 7 +
>>> security/selinux/include/objsec.h | 43 ++-
>>> security/selinux/netlabel.c | 69 ++--
>>> security/selinux/ss/services.c | 18 +-
>>> security/smack/smack.h | 34 ++
>>> security/smack/smack_access.c | 14 +-
>>> security/smack/smack_lsm.c | 388 ++++++++++---------
>>> security/smack/smack_netfilter.c | 48 ++-
>>> security/smack/smackfs.c | 23 +-
>>> 60 files changed, 1855 insertions(+), 961 deletions(-)
>>>
>>
More information about the Linux-security-module-archive
mailing list