[PATCH 00/19] smack: clean up xattr handling

[Konstantin Andreev]

Casey Schaufler, 26 Jul 2025:
> On 7/24/2025 6:09 AM, Konstantin Andreev wrote:
>> A set of minor bug fixes and optimizations in Smack xattr handling.
>> Logically independent, but with the code dependencies.
> 
> Please break this into two (or more) patch sets. The patches regarding
> restrictions on getting and setting the file type specific attributes
> should be presented independently of the xattr "fixes".

Hi, Casey.

Each patch in the set is finite by itself,
addresses an independend issue, and I ought
to send them separately. There are several reasons
why I ended up to collect them into the set:

   1) they are very small and have common subject
   2) they have code dependencies
   3) the feedback time for Smack patches may be high,
      and sending patches one-by-one may be long.
   4) to give you an overview of the offered changes


May it be suitable for you to consider this set
as independent patches, that require, however,
the specific order of applying?

With this approach you could stop considering the
sequence at the 1st unacceptable/wrong/failed patch.

Else, I can collect them into two (or more) patch sets.

> There appears to be a misunderstanding regarding "valid" Smack labels.
> A Smack label is a text string. The intention is that a label is "valid"
> if the system is exposed to it. For example,
> 
> 	# echo Oatmeal > /proc/self/attr/smack/current
> 
> should introduce "Oatmeal" as a Smack label if is has never been used
> before. After a reboot the system may find the label "Bacon" on a file,
> and if the label isn't known it is imported.

I think I understand this.

> Similarly, if a CIPSO packet
> includes a label that has not been seen in is added.

I have never seen this. The unseen CIPSO label is not added,
instead, the incoming packet is marked with `*' label.

Just rechecked, it's so. E.g., tcp/ipv4 connection,
listener side writes the audit record like:

| lsm=SMACK fn=smack_socket_sock_rcv_skb action=denied subject="*" object="foo" requested=w ...

when incoming CIPSO has [bar 250/2,3,7,10,11,16,18,19,20,23]
at the initiator, but unseen at the listener side.

The documentation does not define either way of processing
of the unseen Cipso labels, but current implementation looks
reasonable, as sheer import of network-provided labels
has no limits and opens the door for denial of service.

> This policy is necessary in part because there is a valid use case for
> a Smack label with no explicit access rules.
> 
> I tried out the combined set and encountered many unexpected failures.
> 
[... skip ...]