SELinux violations on Fedora 31

dimitri · April 24, 2020, 11:00am

I saw SELinux violations while uninstalling the authy snaps on a freshly installed Fedora 31 machine. Unfortunately this is not 100% reproducible.

Here are the audit logs, they have to do with /home/username/snap/authy/1/.config/user-dirs.locale as far as I can see:

SELinux is preventing tar from getattr access on the file /home/username/snap/authy/1/.config/user-dirs.locale.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/home/username/snap/authy/1/.config/user-dirs.locale default label should be snappy_home_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /home/username/snap/authy/1/.config/user-dirs.locale

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that tar should be allowed getattr access on the user-dirs.locale file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'tar' --raw | audit2allow -M my-tar
# semodule -X 300 -i my-tar.pp


Additional Information:
Source Context                system_u:system_r:snappy_t:s0
Target Context                unconfined_u:object_r:config_home_t:s0
Target Objects                /home/username/snap/authy/1/.config/user-
                              dirs.locale [ file ]
Source                        tar
Source Path                   tar
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-3.14.4-50.fc31.noarch
Local Policy RPM              <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 5.5.17-200.fc31.x86_64
                              #1 SMP Mon Apr 13 15:29:42 UTC 2020 x86_64 x86_64
Alert Count                   1
First Seen                    2020-04-24 11:16:28 CEST
Last Seen                     2020-04-24 11:16:28 CEST
Local ID                      c4c07830-2176-4b55-801d-968e19f9e8ff

Raw Audit Messages
type=AVC msg=audit(1587719788.414:301): avc:  denied  { getattr } for  pid=2522 comm="tar" path="/home/username/snap/authy/1/.config/user-dirs.locale" dev="dm-0" ino=305825 scontext=system_u:system_r:snappy_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file permissive=1


Hash: tar,snappy_t,config_home_t,file,getattr

SELinux is preventing snapd from unlink access on the file user-dirs.locale.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that snapd should be allowed unlink access on the user-dirs.locale file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'snapd' --raw | audit2allow -M my-snapd
# semodule -X 300 -i my-snapd.pp


Additional Information:
Source Context                system_u:system_r:snappy_t:s0
Target Context                unconfined_u:object_r:config_home_t:s0
Target Objects                user-dirs.locale [ file ]
Source                        snapd
Source Path                   snapd
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-3.14.4-50.fc31.noarch
Local Policy RPM              <Unknown>
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 5.5.17-200.fc31.x86_64
                              #1 SMP Mon Apr 13 15:29:42 UTC 2020 x86_64 x86_64
Alert Count                   1
First Seen                    2020-04-24 11:16:28 CEST
Last Seen                     2020-04-24 11:16:28 CEST
Local ID                      9be0b446-a474-4114-931f-2e6fde062fd6

Raw Audit Messages
type=AVC msg=audit(1587719788.922:306): avc:  denied  { unlink } for  pid=2417 comm="snapd" name="user-dirs.locale" dev="dm-0" ino=305825 scontext=system_u:system_r:snappy_t:s0 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file permissive=1


Hash: snapd,snappy_t,config_home_t,file,unlink

mborzecki · April 24, 2020, 12:40pm

Thanks. I think I have debugged this one. I suspect this line here is a problem:

github.com

ubuntu/snapcraft-desktop-helpers/blob/622e2aa7a840b3a7dbb6ea4d432d687d5cc2e8ef/common/desktop-exports#L169


fi
if can_open_file "$REALHOME/.config/user-dirs.dirs"; then
  # shellcheck disable=SC2154
  if [ "$needs_update" = true ] || [ "$needs_xdg_reload" = true ]; then
    sed "/^#/!s#\$HOME#${REALHOME}#g" "$REALHOME/.config/user-dirs.dirs" > "$XDG_CONFIG_HOME/user-dirs.dirs"
    md5sum < "$REALHOME/.config/user-dirs.dirs" > "$XDG_CONFIG_HOME/user-dirs.dirs.md5sum"
    # It's possible user-dirs.dirs exists when user-dirs.locale doesn't. This
    # simply means the user opted to never ask to translate their user dirs
    if can_open_file "$REALHOME/.config/user-dirs.locale"; then
      cp -a "$REALHOME/.config/user-dirs.locale" "$XDG_CONFIG_HOME"
      md5sum < "$REALHOME/.config/user-dirs.locale" > "$XDG_CONFIG_HOME/user-dirs.locale.md5sum"
    elif [ -f "$XDG_CONFIG_HOME/user-dirs.locale.md5sum" ]; then
      rm "$XDG_CONFIG_HOME/user-dirs.locale.md5sum"
    fi
    needs_xdg_reload=true
  fi
else
  needs_xdg_update=true
  needs_xdg_links=true
fi

It does cp -a, so the original config_home_t label will be preserved inside $HOME/snap/<snap>, which is unexpected. The snapd policy allows manage operations on snappy_home_t which is normally used for $HOME/snap. We do trigger a transition by calling restorecon, but only when we detect that $HOME/snap (the top level dir) does not have snappy_home_t, like it was the case before I started cleaning up the policy.

Maybe we should allow snapd to manage config_home_t (implied for ~/.config), but aside from this problem, I don’t see such need.