SELinux denials for systemd processes

Project Discussion
1

Hello all,

I’m seeing SELinux denials for system processes and files which are part of the read-only deployment - but only on a single machine. Since I’m running out of ideas I’d like to continue here.

For now I’m running this system in Permissive mode which I’d like to avoid.

If running on Enforced, setroubleshoot shows:
SELinux is preventing (-localed) from remount access on the filesystem which let’s localed.service fail and all apps relying on it.

setroubleshoot is suggesting a device relabel, which is not possible on SB.

The full setroubleshoot log is showing system_u:object_r:unlabeled_t. May this be the main culprit?

I’ve already tried running with a clean (reset) deployment. Only nvidia packages from RPMFusion enabled as this is required to boot my system without success.

The full setroubleshoot log:

SELinux is preventing (-localed) from remount access on the filesystem .

*****  Plugin file (73.6 confidence) suggests   ******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot

*****  Plugin file (73.6 confidence) suggests   ******************************

If you think this is caused by a badly mislabeled machine.
Then you need to fully relabel.
Do
touch /.autorelabel; reboot

*****  Plugin catchall (2.93 confidence) suggests   **************************

If you believe that (-localed) should be allowed remount access on the  filesystem 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 '(-localed)' --raw | audit2allow -M my-localed
# semodule -X 300 -i my-localed.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:unlabeled_t:s0
Target Objects                 [ filesystem ]
Source                        (-localed)
Source Path                   (-localed)
Port                          <Unknown>
Host                          mershl-desktop
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.5-43.fc32.noarch
Local Policy RPM              
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     mershl-desktop
Platform                      Linux mershl-desktop 5.8.4-200.fc32.x86_64 #1 SMP
                          Wed Aug 26 22:28:08 UTC 2020 x86_64 x86_64
Alert Count                   16
First Seen                    2020-08-11 21:01:55 CEST
Last Seen                     2020-09-02 00:45:41 CEST
Local ID                      05458b08-18d2-4ec6-b113-2e7aa0ce0756

Raw Audit Messages
type=AVC msg=audit(1599000341.724:236): avc:  denied  { remount } for  pid=6985 comm="(ostnamed)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=filesystem permissive=1


Hash: (-localed),init_t,unlabeled_t,filesystem,remount
2

To do SELinux relabeling on your system, you will have to use restorecon directly on the files/folders that you want to relabel.

Have you recently added a new disk or new mount point? systemd may have tripped over it if it’s not labelled properly.

2 Likes
3

So far I’ve done the troubleshooting steps of fedora docs and yesterday even done a clean install of SB32 without the nvidia drivers. The issue is still visible - only on this single machine.

As it’s always a “remount” action which is denied, can this be related to the hardware setup? I have a pure data storage /mnt/hdd harddrive and a /run/media external harddrive connected.

4

Post the output:

lsblk -o +FSTYPE,UUID
1 Like
5 
NAME MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT FSTYPE UUID
sda    8:0    0 223,6G  0 disk                   
├─sda1
│      8:1    0   128M  0 part                   
└─sda2
       8:2    0 223,5G  0 part            ntfs   C47CCF7C7CCF67AE
sdb    8:16   0 111,8G  0 disk                   
├─sdb1
│      8:17   0   300M  0 part            ntfs   4E74907E74906B0B
├─sdb2
│      8:18   0   100M  0 part            vfat   8291-DA03
├─sdb3
│      8:19   0   128M  0 part                   
├─sdb4
│      8:20   0 110,8G  0 part            ntfs   108EAD368EAD156E
└─sdb5
       8:21   0   550M  0 part            ntfs   F2E8F00FE8EFCFC1
sdc    8:32   0   2,7T  0 disk                   
├─sdc2
│      8:34   0 828,3G  0 part            ntfs   DADE9478DE944E9F
└─sdc3
       8:35   0   1,9T  0 part /var/mnt/h ext4   cda61561-caa8-4526-89f3-d2b4985ea176
sdd    8:48   0 931,5G  0 disk                   
├─sdd1
│      8:49   0   128M  0 part /boot/efi  vfat   220D-020C
├─sdd2
│      8:50   0   300M  0 part /boot      ext4   f28d8bad-c53d-4c74-b6c3-496abe2484fe
├─sdd3
│      8:51   0   7,9G  0 part [SWAP]     swap   4af7bbd8-5b66-4977-bfd0-4c06d6a41ce2
└─sdd4
       8:52   0 923,2G  0 part /sysroot   ext4   afb985ac-f073-4586-832c-daf5fe907241
sde    8:64   0   3,7T  0 disk                   
├─sde1
│      8:65   0   128M  0 part                   
└─sde2
       8:66   0   3,7T  0 part /run/media exfat  1C21-C736
1 Like
6 
grep -e /mnt -e /run/media /etc/mtab /etc/fstab
1 Like
7

EDIT: I forgot about a network share. Remembered when you changed the grep to /mnt.

EDIT2: I re-used my fstab after the clean installation. Sorry for the confusion.

$ grep -e /mnt -e /run/media /etc/mtab /etc/fstab
/etc/mtab:systemd-1 /var/mnt/nas_media autofs rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=6413 0 0
/etc/mtab:systemd-1 /sysroot/ostree/deploy/fedora/var/mnt/nas_media autofs rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=6413 0 0
/etc/mtab:/dev/sdc3 /var/mnt/hdd-home ext4 rw,seclabel,nosuid,nodev,relatime 0 0
/etc/mtab:/dev/sde2 /run/media/mershl/MyPassport exfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro 0 0
/etc/fstab://192.168.178.196/media         /mnt/nas_media   cifs    uid=0,credentials=/root/.smb,iocharset=utf8,vers=3.0,noperm,noauto,x-systemd.automount 0 0
/etc/fstab:/dev/disk/by-uuid/cda61561-caa8-4526-89f3-d2b4985ea176 /mnt/hdd-home auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=hdd-home 0 0
1 Like
8

Can you take a look a the SELinux labels for those mount points with ls -Z ...?

2 Likes
9 
$ ls -lZ /var/mnt
drwxr-xr-x. 2 root   root   system_u:object_r:cifs_t:s0    0 19. Jul 23:18 nas_media
drwxr-xr-x. 6 mershl mershl system_u:object_r:var_t:s0  4096 11. Jul 17:19 hdd-home
$ ls -lZ /run/media/mershl
drwxr-xr-x. 42 mershl mershl system_u:object_r:unlabeled_t:s0 1048576  2. Sep 12:49 MyPassport
1 Like
10

Apparently exfat does not support extended attributes, so you will have to manually mount this disk by setting a custom SELinux context:

$ cat /etc/systemd/system/mount-path-here.mount
[Unit]
Description=External disk

[Mount]
What=/dev/disk/by-label/MyPassport
Where=/mount/path/here
Type=exfat
Options=rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro,context=system_u:object_r:mnt_t:s0,fscontext=system_u:object_r:mnt_t:s0

[Install]
WantedBy=multi-user.target

This is potentially a bug to report to the SELinux policy. You may also try with the dosfs_t type.

2 Likes
11

Upstream PR submitted as: kernel/filesystem: Add exfat support (no extended attributes) by travier · Pull Request #425 · fedora-selinux/selinux-policy · GitHub

2 Likes
12

Thank you very much for the support and information @siosm and @vgaetera.

I’ve also created a bugzilla to track this issue for Fedora: 1874836 – SELinux is preventing (-localed) from remount access on the filesystem while exfat drive is mounted. Maybe you can add your PR as a comment.

@siosm: Will I need to trigger a restorecon for the mountpoint once your policy change goes live?

1 Like
13

You should not need a restorecon (and I don’t think it would work). It should work directly once you’ve updated and rebooted to a Silverblue version with the fix.

2 Likes