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

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

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?

> 
> > CONFIG_CRC_CCITT=y
> > 
> > CONFIG_EXT4_FS_SECURITY=y
> > 
> > CONFIG_TMPFS_XATTR=y
> > 
> > CONFIG_SQUASHFS_XATTR=y
> > 
> > 
> > Steps to reproduce the issue:
> 
> Thank you for the detailed report. I will look into
> the problem today.
> 
> > On qemu:
> > * Setup qemu with network connection to the host via tap device.
> > * Add ip6host label via smackfs:
> > 
> > echo "<host-ipv6-addr> net_host" > /sys/fs/smackfs/ipv6host
> > 
> > * Add rule for allowed network traffic:
> > 
> > echo "tcp_test net_host w" > /sys/fs/smackfs/load2
> > 
> > * The following script was used for listening for packets on qemu:
> > 
> > cat << EOF > tcp_listen.sh
> > #!/bin/sh
> > while true;
> > do
> >     socat - TCP6-LISTEN:\$1,reuseaddr,fork > /dev/null & ps=\$!
> >     sleep 1
> >     kill -9 \$ps
> > done
> > EOF
> > 
> > * Start the script twice, one allowing, one denying traffic via
> > SMACK:
> > 
> > echo tcp_test > /proc/self/attr/current && sh tcp_listen.sh 12345
> > 2>&1
> > /dev/null &
> > echo tcp_test2 > /proc/self/attr/current && sh tcp_listen.sh 12346
> > 2>&1
> > /dev/null &
> > 
> > * Start 'stress' to generate system load with 'stresstest' as SMACK
> > label:
> > 
> > echo stresstest > /proc/self/attr/current && stress -c 2 -i 4 -m 2
> > --
> > vm-bytes 64M &
> > 
> > 
> > On host:
> > * Generate random data to send via network:
> > 
> > dd if=/dev/urandom of=test/data bs=1M count=10
> > 
> > * Use the following script to continously send packets:
> > 
> > cat << EOF > packet_tcp.sh
> > #!/bin/sh
> > while true;
> > do
> >     cat data | nc <qemu-ipv6-addr> \$1
> > done
> > EOF
> > 
> > * Execute the script twice to address both receiving applications
> > on
> > qemu:
> > 
> > bash packet_tcp.sh 12345 2>&1 > /dev/null &
> > bash packet_tcp.sh 12346 2>&1 > /dev/null &
> > 
> > 
> > Observing the problem:
> > 
> > After letting this run for ~5-10 mins only audit messages regarding
> > the
> > label 'tcp_test2' are expected.
> > The issues can be seen, that also other labels are randomly
> > appearing
> > in the logs (most commonly here 'stresstest', probably since it
> > occupies most of the cpu time):
> > 
> > journalctl | grep action=denied | grep -v tcp_test2
> > 
> > 
> > Example entry with kernel 6.0-rc2:
> > Aug 24 12:38:32 buildroot audit[609]: AVC lsm=SMACK
> > fn=smk_ipv6_check
> > action=denied subject="net_host" object="stresstest" requested=w
> > pid=609 comm="stress" saddr=<host-ipv6-addr> dest=50714
> 
> This may be an issue with the audit record generation including the
> wrong object label. It has been noticed before. I will look more
> closely.
> 
> > If you are missing additional info please reach out to me.
> > Thank you in advance and best regards,
> > 
> > Michael Lontke