Silverblue rawhide 2019-02-05 selinux labels missing


#1

hi *,

i was playing around getting stumpwm running on silverblue rawhide and tried to install a .desktop file for gdm. i dropped the file in /etc/X11/session which did not work, so i thought it might be an issue with a selinux label. so i ran fixfiles restore /etc/X11 which did not change anything, so i manually ran chcon -u system_u /etc/X11/sessions/stumpwm.session which changed the user to system_u. so far so good :slight_smile:

but after rebooting it seems that all selinux labels on the filesystem got reset to default_t. maybe (or for sure…) i did something completely stupid while hacking around…
i’m currently looking only at systemd as starting various services failed because of this.

# ls -laZ /usr/lib/systemd/systemd
-rwxr-xr-x. 4 root root system_u:object_r:default_t:s0 2402648 Jan  1  1970 /usr/lib/systemd/systemd

on a silverblue vagrant box which is working fine this yields

# ls -laZ /usr/lib/systemd/systemd
-rwxr-xr-x. 4 root root system_u:object_r:init_exec_t:s0 2402648 Dec 31  1969 /usr/lib/systemd/systemd

looking at more files it seems all domains got reset to default_t

what is the recommend way to restore the right selinux labels under silverblue?

i tried touching /.autorelabel, but of course this does not work on silverblue. fixfiles -F onboot also fails because of this:

# ]# fixfiles -F onboot
/usr/sbin/fixfiles: line 313: /.autorelabel: Operation not permitted

i’m currently running selinux in permissive mode, but a fix without reinstalling would be great :slight_smile:

hope this is the right channel to ask

thanks for your time and help
toni


#2

Try doing semodule -B to rebuild the SELinux policy after you reboot.

This should be a better experience soon, as the following changes will soon land upstream:


#3

thanks for the hint. semodule -B worked. fixfiles check /usr/lib/systemd now reports that it would fix the labels. problem is that fixfiles restore /usr/lib/systemd is not able to modify /usr (as expected on silverblue). so the question is how to relabel files in /usr in silverblue?

i could probably run fixfiles/restorecon in /sysroot/ostree/deploy/fedora-workstation/deploy and relabel the ostree checkouts, but is this a good idea?

thanks
toni


#4

Files under /usr should always have the correct label since those are part of the OSTree object itself. If they’re not labeled correctly, then your repo might somehow be corrupted. Does ostree fsck return any errors for you? Hmm… unless you have layered packages that are affecting your policy. rpm-ostree status -v would be helpful. There’s an outstanding issue related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1669982

(By contrast, files in /etc and /var could become mislabeled depending on what you’re doing and so restorecon on those could make sense.)


#5

so running ostree fsck prints the following:

# ostree fsck
Validating refs...
Validating refs in collections...
Enumerating objects...
Verifying content integrity of 397 commit objects...
fsck objects (5279/153851) [             ]   3%
error: In commits a6b10956f6ccb594101a9364d52fdb0ae6ff63dda481fa1e9d5419b7c39c38d0,    170b5b15e9f5c87a70a87292c7acada05cbcbf2c87e77a3b2215ec54ca6e541, d835dda62628c4bfab1227ef4632b15ff4cf5f5f53fb8d41313b5d9665422d9a, 6a6cf75d41f6728710e633641616c4872db483103e63e4eda57fb949e11c574f: fsck content object  aa08adff098b9e5c111b5c8c07bba9e9fb07037d31872287ca99652ecb7f54b8: Corrupted file object; checksum expected='aa08adff098b9e5c111b5c8c07bba9e9fb07037d31872287ca99652ecb7f54b8' actual='0322019cc6c7b6222bd657b64e8a0d7118d043bc7fcf80829ec5f984a098352f'

is there a way to fix this?

and yes, i did install quite a few layered packages:

LayeredPackages: autoconf dmenu emacs gcc 'gcc-c++' gmime-devel html2text i3 i3status isync java-11-openjdk make rdesktop rlwrap sbcl sway terminus-fonts texinfo texlive tigervnc vinagre xapian-core-devel xcape xscreensaver xterm

most of them could be moved to a container, i’ll try to clean that up asap.

thanks for helping out!

toni


#6

I believe you should be able to just re-pull the corrupted commits:

# ostree pull <remote-name>:<ref> <commit>

I just successfully did the following:

$ sudo ostree pull fedora-workstation:fedora/29/x86_64/silverblue a6b10956f6ccb594101a9364d52fdb0ae6ff63dda481fa1e9d5419b7c39c38d0


GPG: Verification enabled, found 1 signature:

  Signature made Tue 12 Feb 2019 08:28:54 PM EST using RSA key ID A20AA56B429476B4
  Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"
1 metadata, 0 content objects fetched; 569 B transferred in 3 seconds