[00/90] LSM: Module stacking for all
mbox series

Message ID 20190419004617.64627-1-casey@schaufler-ca.com
Headers show
Series
  • LSM: Module stacking for all
Related show

Message

Casey Schaufler April 19, 2019, 12:44 a.m. UTC
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.

git://github.com/cschaufler/lsm-stacking.git#stack-5.1-v2-full

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               | 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(-)

Comments

Stephen Smalley April 19, 2019, 3:27 p.m. UTC | #1
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.

> 
> git://github.com/cschaufler/lsm-stacking.git#stack-5.1-v2-full
> 
> 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               | 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(-)
>
Casey Schaufler April 21, 2019, 5:31 p.m. UTC | #2
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.


>
>>
>> git://github.com/cschaufler/lsm-stacking.git#stack-5.1-v2-full
>>
>> 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               | 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(-)
>>
>
Stephen Smalley April 22, 2019, 12:46 p.m. UTC | #3
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@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(-)
>>>
>>
Casey Schaufler April 22, 2019, 4:10 p.m. UTC | #4
On 4/22/2019 5:46 AM, Stephen Smalley wrote:
> 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,

SELinux doesn't. Smack does. Smack always enables labeled networking.


> so there is no real conflict until/unless someone configures labeled 
> networking for SELinux.

Labeled networking is independent of the security modules.
Netlabel provides mechanism and leaves policy up to whoever
might look at the lsm_secattr. Once Smack sets the default
labeling everyone get the labels.

> 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?

Exporting security information, either by netlabel, netfilter
secmarks or security contexts has always been the challenge.
User space has never had to deal with the possibility that
there might be more than one security module to deal with.
A system that assumes a particular security module, as do
Fedora and Ubuntu, will have some opportunities for improvement
in the full stacking world.

I have been using Fedora 29 as a primary testbed. The
Fedora user space expects SELinux and so long as SELinux
appears before Smack in the LSM list, it's happy except
for the networking. If you put Smack ahead of SELinux the
user space fails when it tries to get or set SELinux
attributes. This is because the kernel uses the first
module providing the interfaces like SO_PEERSEC, and the
code only wants to see SELinux attributes.

I'm not 100% sure I can explain the behavior of overlayfs
in the combined environment, but then I'm not sure I really
understand how it's expected to work in any case.