Silverblue rawhide 2019-02-05 selinux labels missing

tosmi · 2019-02-11T08:49:49.854Z

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

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

hope this is the right channel to ask

thanks for your time and help
toni

miabbott · 2019-02-11T13:58:33.921Z

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:

github.com/projectatomic/rpm-ostree

libpriv: Rebuild policy during postprocessing

by jlebon on 05:14PM - 06 Feb 19 UTC

4 commits changed 3 files with 46 additions and 4 deletions.

tosmi · 2019-02-11T16:03:08.951Z

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

jlebon · 2019-02-12T14:50:39.816Z

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.)

tosmi · 2019-02-12T18:01:22.786Z

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

miabbott · 2019-02-13T16:18:44.031Z

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

tosmi · 2019-02-26T17:32:35.541Z

just a quick update: i actually reinstalled silverblue to finally fix this issues. mounting /usr rw and running fixfiles somehow worked, but the links in / (e.g bin, sbin) still had wrong labels. as i was unsure if everything was labeled correctly i simply reinstalled.

thanks for your help

refi64 · 2019-02-26T18:35:06.307Z

tosmi:

mounting /usr rw and running fixfiles somehow worked

Yeah that might have ended up breaking anyway…

mmello · 2019-04-14T06:15:11.559Z

Hello guys,

I ended having the same problem. Do you think a rebase would fix the problem?

$ sudo rpm-ostree  status
State: idle
AutomaticUpdates: disabled
Deployments:
● ostree://fedora-workstation:fedora/29/x86_64/silverblue
                   Version: 29.20190414.0 (2019-04-14T02:02:26Z)
                BaseCommit: 2b3cddc07d0cf38f5b7165df2c8fb1ed245f13e68d7c9cb2f402648d3ebba685
              GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4


$ sudo ostree  fsck
Validating refs...
Validating refs in collections...
Enumerating objects...
Verifying content integrity of 326 commit objects...

error: In commits e54508319b326f1ce5ed6aa2f5a9bd5927c59a78f80f27e0cfbe489f375da3c6, 0d5e32c3e75c5caadef0be36884e1edf8d310804555005bf3946271d0ac89486, 4fdc573209851bf33694d24254c30c92835920a0bfd0cea52c152fe93757f258: fsck content object 194b5188d49a9d14c0e7e01c528e7248e4f776116d519abaa2ec30ccf47aeb28: Corrupted file object; checksum expected='194b5188d49a9d14c0e7e01c528e7248e4f776116d519abaa2ec30ccf47aeb28' actual='d816c3c8e18e8c5362e8608310fd0f90824ecad1b9348dbf80a7033ed2893f6c'

tosmi · 2019-04-21T15:13:07.777Z

i’m not sure how to really fix this issue. i think i did a rebase once but this didn’t fix anything. but you could try it anyways. relabeling everything somehow worked, but i still had minor issues (some services still failing). the only real fix for me was to reinstall.

in a standard installation of rhel/fedora you could always touch /.autorelabel and reboot, but imho this does not work for silverblue.

one outcome of the above was that i only install a minimal set of overlay packages (like i3) and everything else is running inside a toolbox container (you could also use flatpak). i think this the way to go with silverblue anyways.

sorry that i cannot provide an easy fix for that issue

toni

fansari · 2019-05-03T18:45:20.263Z

Same issue here. In bugzilla someone told me to do a “restorecon -rv /” after I reported an SELinux issue.

Now my system is broken. In enforcing mode I do not even reach the login prompt.

I tried the “semodule -B” hint and also this

ostree pull fedora-workstation:fedora/30/x86_64/silverblue 
 8d936a527b68fbfd50837a9bdc016cc00e389e7bf0541666d6eb6513fcd271a2

but none of this fixed the issue. I cannot login anymore in enforcing mode.