Re: SMACK: access is granted while smack-utils report that it shouldn't be
From: Casey Schaufler <casey@schaufler-ca.com>
Date: 2021-11-17 01:52:46
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