Linux Security Modules development
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: "Lontke, Michael" <Michael.Lontke@elektrobit.com>
Cc: "Ostertag, Martin" <Martin.Ostertag@elektrobit.com>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"Weiß, Simone" <Simone.Weiss@elektrobit.com>,
	"Valleru, Yuvarajesh" <Yuvarajesh.Valleru@elektrobit.com>,
	"Irgang, Thomas" <Thomas.Irgang@elektrobit.com>,
	casey@schaufler-ca.com
Subject: Re: SMACK LSM checks wrong object label during ingress network traffic
Date: Fri, 26 Aug 2022 09:15:22 -0700	[thread overview]
Message-ID: <2d4958bd-dc67-8244-c688-eed4feb64ba8@schaufler-ca.com> (raw)
In-Reply-To: <0e3266a5c93229b29c10a0a7b68232000453aabf.camel@elektrobit.com>

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.


  reply	other threads:[~2022-08-26 16:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25  9:25 SMACK LSM checks wrong object label during ingress network traffic Lontke, Michael
2022-08-25 15:59 ` Casey Schaufler
2022-08-26  8:40   ` Lontke, Michael
2022-08-26 16:15     ` Casey Schaufler [this message]
2022-08-30  9:30       ` Lontke, Michael
2022-08-30 14:06         ` Casey Schaufler
2022-08-31 12:13           ` Lontke, Michael
2022-08-31 14:38             ` Casey Schaufler
2022-09-01  8:40               ` Lontke, Michael
2022-09-01 16:26                 ` Casey Schaufler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d4958bd-dc67-8244-c688-eed4feb64ba8@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=Martin.Ostertag@elektrobit.com \
    --cc=Michael.Lontke@elektrobit.com \
    --cc=Simone.Weiss@elektrobit.com \
    --cc=Thomas.Irgang@elektrobit.com \
    --cc=Yuvarajesh.Valleru@elektrobit.com \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox