Unable to start in enforcing

[bhartlovecode]

Unable to start in enforcing

[dburgener]

Hey, thanks for the quick testing of the sample policy and the bug report.

Can you reboot in permissive and grab the journal log and share that (journalctl -b 0 > journal.txt)?

Likely issues would contain either a log entry with the string "AVC" or the string "SELinux", but there are a number of things that could cause a boot hang (either SELinux denials, or failures in SELinux aware userspace components such as systemd, dbus, xwayland and others). Each of the different user daemons has its own logging, so it's hard to say precisely what to look for in the abstract. If you are able to share the full log, I'll take a look through it and should be able to zero in on the problem from there.

[bhartlovecode]

Thank you for the help and quick response. I've attached my journal.txt as requested. I did see some AVC denials in there.
journal.txt

[dburgener]

Thanks for the logs. It looks like everything is fine up until this point and at least most of what follows seems to be consequences of this part:

Jan 26 18:34:33 fedora.example.com audit[1]: AVC avc:  denied  { search } for  pid=1 comm="systemd" name="/" dev="dm-0" ino=128 scontext=system_u:system_r:kernel_sid tcontext=system_u:object_r:unlabeled_sid tclass=dir permissive=1
Jan 26 18:34:33 fedora.example.com audit[1]: AVC avc:  denied  { getattr } for  pid=1 comm="systemd" name="systemd" dev="dm-0" ino=299959 scontext=system_u:system_r:kernel_sid tcontext=system_u:object_r:unlabeled_sid tclass=file permissive=1
Jan 26 18:34:33 fedora.example.com audit[1]: AVC avc:  denied  { dyntransition } for  pid=1 comm="systemd" scontext=system_u:system_r:kernel_sid tcontext=system_u:system_r:kernel_sid tclass=process permissive=1
Jan 26 18:34:33 fedora.example.com audit[1]: AVC avc:  denied  { read } for  pid=1 comm="systemd" name="file_contexts" dev="dm-0" ino=22255515 scontext=system_u:system_r:kernel_sid tcontext=system_u:object_r:unlabeled_sid tclass=file permissive=1
Jan 26 18:34:33 fedora.example.com audit[1]: AVC avc:  denied  { ioctl } for  pid=1 comm="systemd" path="/etc/adjtime" dev="dm-0" ino=17328184 ioctlcmd=0x5401 scontext=system_u:system_r:kernel_sid tcontext=system_u:object_r:unlabeled_sid tclass=file permissive=1

There are two issues here: 1. systemd seems to be running as the "kernel_sid" type. It should have transitioned to the "general" domain. 2. Several files are unlabeled, including /, /etc and some of the contents of /etc.

Can you check the labels (ls -Z) on a few files, including /etc and /usr/lib/systemd/systemd? Most of the system should be system_u:object_r:all_files, with the exception of /usr/lib/systemd/systemd, which should be system_u:object_r:init_exec. Double check that you ran restorecon as root and used the -F flag?

[bhartlovecode]

Running ls -Z on those files revealed they both had types of "unlabeled_sid". When I run restorecon -RF /etc/, or any other directory, I get flooded with errors saying the Operation is not supported.

[dburgener]

Thanks. Those errors are definitely relevant. The "Operation is not supported" error indicates that the filesystem doesn't support extended attributes, which are necessary for relabeling. Looking in your logs some more, it seems that you're using xfs for your root, which does have extended attribute support, but it isn't specified in the policy. Would you mind building this PR branch #100 and retesting and see if that resolves your problem?

[bhartlovecode]

Success! I was able to boot into enforcing.

One thing I will note, is I still have two lingering AVCs:

allow kernel_sid self:capability2 syslog;
allow kernel_sid self:system syslog_console;

From the audit.log:

type=AVC msg=audit(1674874943.471:186): avc: denied { syslog } for pid=354 comm="plymouthd" capability=34 scontext=system_u:system_r:kernel_sid tcontext=system_u:system_r:kernel_sid tclass=capability2 permissive=0
type=AVC msg=audit(1674874943.471:186): avc: denied { syslog_console } for pid=354 comm="plymouthd" scontext=sys

Thank you for your help and quick responses!

[dburgener]

Glad it's working for you. Thanks for reporting the AVCs as well. Looks like plymouthd logs to the console in some situations, so it's reasonable to add to the policy. I've made a PR for that. #103