SMACK LSM checks wrong object label during ingress network traffic

[Casey Schaufler]

On 8/30/2022 2:30 AM, Lontke, Michael wrote:
> 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
> nehosttfilter rule to mark the package with secmark:

The netfilter rule is unnecessary if you set the host label. Smack will
set the secmark based on the host label. The approach you've use should
work just fine. Seeing that the problem occurs in both cases will help
narrow down the possibilities. With the configuration and cases you
provided I am able to reproduce the problem reliably. I am working on
tracking down what I think is a lack of locking issue. Any more information
you can provide could be most helpful.

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