SMACK: access is granted while smack-utils report that it shouldn't be

[Casey Schaufler]

On 11/16/2021 5:18 PM, Denis Obrezkov wrote:
> Hi,
>
> I installed smack (enabled it in the kernel and installed smack-utils)
> in my Linux From Scratch distro. I am trying to regulate access with it
> but access is always granted.
>
> I created a file and installed the labels (with attr -S -s ...), they
> were attached:
>
> echo "foobar text" > foobar
>
> # attr -S -g SMACK64 foobar
> Attribute "SMACK64" had a 8 byte value for foobar:
> objlabel
>
> # attr -S -g SMACK64EXEC /bin/cat
> Attribute "SMACK64EXEC" had a 9 byte value for /bin/cat:
> subjlabel
>
> I wrote simple rules, reading is forbidden:
>
> echo subjlabel objlabel -w--- > /sys/fs/smackfs/load2
> # smackaccess subjlabel objlabel w
> 1
> # smackaccess subjlabel objlabel r
> 0
>
> but when I try to read the file I succeed:
>
> # cat foobar
> foobar text
>
> And the relevant output in dmesg shows that the access was granted:
>
> [ 4341.952360] audit: type=1400 audit(1637110820.839:108): lsm=SMACK
> fn=smack_inode_permission action=granted subject="subjlabel"
> object="objlabel" requested=r pid=427 comm="cat" name="foobar"
> dev="sda1" ino=820571
> [ 4341.955501] audit: type=1400 audit(1637110820.839:109): lsm=SMACK
> fn=smack_file_open action=granted subject="subjlabel" object="objlabel"
> requested=r pid=427 comm="cat" path="/root/foobar" dev="sda1" ino=820571
> [ 4341.958411] audit: type=1400 audit(1637110820.839:110): lsm=SMACK
> fn=smack_inode_getattr action=granted subject="subjlabel"
> object="objlabel" requested=r pid=427 comm="cat" path="/root/foobar"
> dev="sda1" ino=820571
>
> What can be the problem?

Smack is integrated with the Linux privilege model.
Smack policy can be modified by a process that possesses
CAP_MAC_ADMIN. This includes setting labels on files,
changing its own process label and creating Smack access
rules. Smack access policy can be violated by a process
that possesses CAP_MAC_OVERRIDE. Today's Linux distributions
give root processes all capabilities, including these two.

Your problem is that you are running as root.

You can restrict CAP_MAC_ADMIN and CAP_MAC_OVERRIDE to
processes running with specific Smack labels using the
onlycap feature. I suggest that you defer playing with
that for the time being as it is quite easy to create
non-functional systems using onlycap.

You may find the Tizen documentation helpful:

	https://wiki.tizen.org/Security:TizenSmackReferencePolicy