Re: SMACK LSM checks wrong object label during ingress network traffic

["Lontke, Michael" <Michael.Lontke@elektrobit.com>]

On Fri, 2022-08-26 at 09:15 -0700, Casey Schaufler wrote:
> On 8/26/2022 1:40 AM, Lontke, Michael wrote:
> > On Thu, 2022-08-25 at 08:59 -0700, Casey Schaufler wrote:
> > > On 8/25/2022 2:25 AM, Lontke, Michael wrote:
> > > > Hello Mr. Schaufler,
> > > > 
> > > > we observed the following behavior of the SMACK LSM kernel
> > > > feature.
> > > > 
> > > > PROBLEM: SMACK LSM is checking the wrong label when receiving
> > > > network
> > > > packets during high system load.
> > > > 
> > > > Full Descrpition of the Problem: During a test scenario
> > > > involving
> > > > high
> > > > system load (cpu, memory and io) in combination with ingress
> > > > tcp
> > > > network traffic, SMACK is checking wrong object labels leading
> > > > to
> > > > denied access for valid scenarios.
> > > > In below test scenario the label 'stresstest' is only used for
> > > > the
> > > > application 'stress' but appears in SMACK audit logs as object
> > > > together
> > > > with netlabels.
> > > > 
> > > > This issue initially appeared on hardware with kernel version
> > > > 4.14.237
> > > > but was also being reproduced with qemu for kernel version
> > > > 4.14.290
> > > > and
> > > > latest 6.0-rc2. The used rootfs was generated via buildroot
> > > > version
> > > > 2022.08-rc1.
> > > > 
> > > > 
> > > > KEYWORDS: smack, networking
> > > > 
> > > > KERNEL INFORMATION: Linux stable kernel
> > > > 
> > > > KERNEL VERSION: 4.14.237, 4.14.290, 6.0-rc2
> > > > 
> > > > 
> > > > KERNEL CONFIG: smack related kernel configuration
> > > > 
> > > > CONFIG_NETLABEL=y
> > > > 
> > > > CONFIG_SECURITY_NETWORK=y
> > > > 
> > > > CONFIG_SECURITY_SMACK=y
> > > > 
> > > > CONFIG_DEFAULT_SECURITY_SMACK=y
> > > > 
> > > > CONFIG_DEFAULT_SECURITY="smack"
> > > 
> > > What is the value for CONFIG_SECURITY_SMACK_NETFILTER ?
> > 
> > # CONFIG_NETWORK_SECMARK is not set
> > therefore CONFIG_SECURITY_SMACK_NETFILTER is not set as well.
> > 
> > > The implementation for IPv6 is much more robust for the
> > > netfilter enabled path.
> > 
> > You are stating that
> > 
> > CONFIG_NETWORK_SECMARK=y
> > CONFIG_SECURITY_SMACK_NETFILTER=y
> > 
> > and therefore using SMACK_IPV6_SECMARK_LABELING instead of
> > SMACK_IPV6_PORT_LABELING path in kernel code is more reliable?
> 
> Yes. The netfilter version is used in all known commercial
> deployments
> of Smack, and hence has gotten more attention. The port labeling code
> is a "clever hack". I hope to replace it with CALIPSO now that
> CALIPSO
> is supported by newlabel.
> 

Today I tested with your suggested configuration (secmark + netfilter).
Executing the same test case I run into almost the same issue:

[  288.200206] audit: type=1400 audit(1661844069.376:742): lsm=SMACK
fn=smack_socket_sock_rcv_skb action=denied subject="net_host"
object="stresstest" requested=w pid=185 comm="stress" saddr=<host-ipv6-
addr> src=49812 daddr=<qemu-ipv6-addr> dest=42511 netif=ens3

Instead of defining the netlabel via /sys/fs/smackfs/ip6hosts I added a
netfilter rule to mark the package with secmark:

ip6tables -t mangle -A INPUT -p tcp --src <host-ipv6-addr> -j SECMARK
--selctx net_host