Fedora coreos41: A valid context for 'user' could not be obtained

Ask Fedora
,
1

After re-enabling selinux on my fcos41 system not able to login due to: ‘A valid context for core could not be obtained’.
This is the sequence of event:

  1. perfectly working system, disabled selinux for some reason
  2. rpm-ostree install vim and re-enabled selinux
  3. after rebooting found myself locked out of system due to ‘A valid context for core could not be obtained’
  4. fortunately from grub screen I could boot with previous deploy where selinux is disabled
  5. rpm-ostree rollback; this is current status:
    -deploy 0: SELINUX=disabled: good
    -deploy 1: SELINUX=enforcing: bad

Need help to re-enable selinux. I am thinking of the following plan:
a) create a new deploy based on current deploy 0 but with SELINUX=permissive → deploy a
b) boot from deploy a, troubleshoot, create deploy b with SELINUX=enforcing
c) boot from deploy c, if ok done, if nok go back to b

Question: how to create a new deploy where the only change is toggle selinux?

2

Would you mind sharing the output of the rpm-ostree status command?

3

Unfortunately dont have ‘rpm-ostree status’ because in the meantime I have deleted the broken deploy, but I have the following logs:

root@mostro:/sysroot/ostree/repo# ostree log ostree/0/0/0
commit 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660
Parent: 8caf08dc8e25f389ade284ad2ad3ef64763e30a63038459d89a616b8725d12a6
ContentChecksum: 02a4df76d30a6e39c4b427652e3bee7761b93627ceb955cd2cc6848a30a77119
Date: 2024-11-25 02:09:37 +0000
Version: 41.20241109.3.0
(no subject)

<< History beyond this commit not fetched >>
root@mostro:/sysroot/ostree/repo# ostree log ostree/0/0/1
commit c88be5ac6a91fa1be5e6dcfa0e3d5a42cc475bb1c105e3feee6c2d25dd0afac8
Parent: 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660
ContentChecksum: bc18675126d78a11b15fbfab02126274cfc8784aa5ea39e5a9a4eebb2dc0a122
Date: 2024-12-07 16:19:59 +0000
Version: 41.20241109.3.0
(no subject)

commit 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660
Parent: 8caf08dc8e25f389ade284ad2ad3ef64763e30a63038459d89a616b8725d12a6
ContentChecksum: 02a4df76d30a6e39c4b427652e3bee7761b93627ceb955cd2cc6848a30a77119
Date: 2024-11-25 02:09:37 +0000
Version: 41.20241109.3.0
(no subject)

<< History beyond this commit not fetched >>
root@mostro:/sysroot/ostree/repo# ostree admin status

  • fedora-coreos 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660.0
    Version: 41.20241109.3.0
    origin refspec: fedora:fedora/x86_64/coreos/stable
    GPG: Signature made Mon Nov 25 02:11:25 2024 using RSA key ID D0622462E99D6AD1
    GPG: Good signature from “Fedora fedora-41-primary@fedoraproject.org”
    fedora-coreos c88be5ac6a91fa1be5e6dcfa0e3d5a42cc475bb1c105e3feee6c2d25dd0afac8.0 (rollback)
    Version: 41.20241109.3.0
    origin:
4

I’m not sure if I understand the question, could you try to explain it in more detail?

On a fresh FCOS VM installation, following the steps from your initial post, the system is at the following state:

core@localhost:~$ sudo rpm-ostree status 
State: idle
AutomaticUpdatesDriver: Zincati
  DriverState: active; periodically polling for updates (last checked Sun 2024-12-08 16:42:19 UTC)
Deployments:
● fedora:fedora/x86_64/coreos/stable
                  Version: 41.20241109.3.0 (2024-11-25T02:09:37Z)
                   Commit: 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1

  fedora:fedora/x86_64/coreos/stable
                  Version: 41.20241109.3.0 (2024-11-25T02:09:37Z)
               BaseCommit: 870e2c8fd02e81652b30bc9a33b5da9d47de66c8bc2bae0a3739ecf38f652660
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
          LayeredPackages: vim
core@localhost:~$ sudo sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

Could you please also try to describe how and what deployment you deleted, as well as what you are trying to achieve overall?

5

See Clarify position around SELinux support · Issue #439 · coreos/fedora-coreos-docs · GitHub

We don’t support a system going back to SELinux enabled once disabled. You will likely have to re-install it.

If you need to disable SELinux temporarily for a daemon, you should use permissive domains (search the tracker for examples) or full permissive mode (setenforce 0, not recommended but simpler).

6

Hi Bit,

You might want to try booting single user and create a file in the root “/” of the fs called .autorelabel ( /.autorelabel) …
When you disable selinux and then set it back to enforcing, you must do a relable or everything breaks …

7

This is probably an unintentional typo and should possibly be setenforce 0.

1 Like
8

You don’t want to do that on a CoreOS system IIRC as the autorelabeling bits won’t behave properly

9

Hi Dusty,

Yeah … I would call that a serious design flaw … so, there is no recovery outside of:

  1. leave selinux disabled or
  2. have fun rebuilding your system from scratch

OUCH!!!

10

In general:

When anyone disables selinux, the virtual filesystem that holds the labels of the OS are non existent. When you turn selinux back on, labels on the readonly mounts (/ostree /usr) from the system will get an default_t label, which will cause the system to act incorrectly.

/sysroot (as mentioned above)
I have suggested modifying the selinux policy to exclude the relabeling of /sysroot. At that time, I don’t know if I was misunderstood, or that it’s current approach was better, but I abandoned that idea because by making the policy not label /sysroot/* or by there suggestion of making the mount readonly yield the same results when selinux is disabled, including wiping /ostree labels.

Thoughts:
Since these ostree OS’s are a bunch of mounts and symlinks, labels are correctly applied to the whole system including /sysroot. Some labels in /ostree are not relabeled correctly because they are not declared in the selinux policy and may cause some hiccups. But once your system is running again, a simple rpm-ostree upgrade or rpm-ostree rebase would correct /ostree labels.

Opinion:
You have to relabel the whole filesystem. The easiest way I have found to relabel an ostree system is to temporary add autorelabel=1 from your grub commandline before starting the OS because of it’s readonly mounts that block relabeling.

1 Like