`-chardev pipe,id=virtio_console_user,path=virtio_console_user,logfile=virtio_console_user.log,logappend=on -device virtconsole,chardev=virtio_console_user,name=org.openqa.console.virtio_console_user` is the console that winds up being hvc1, I think, but I don't think it matters a lot.

Going to fix the generator issue which is a regresion.
hwdb issue is an effect of the new systemd and is already addressed.
nsresourced is under investigation.

This is not fully fixed in selinux-policy-41.2-1.fc41 . Still no console, and these denials (not all related to this bug, probably, but listing them all for completeness):

Jun 04 02:44:14 localhost kernel: audit: type=1400 audit(1717494254.271:7): avc:  denied  { setfscreate } for  pid=522 comm="systemd-getty-g" scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:systemd_getty_generator_t:s0 tclass=process permissive=0
Jun 04 02:44:14 localhost kernel: audit: type=1400 audit(1717494254.271:8): avc:  denied  { setfscreate } for  pid=522 comm="systemd-getty-g" scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:systemd_getty_generator_t:s0 tclass=process permissive=0
Jun 04 02:44:14 localhost kernel: audit: type=1400 audit(1717494254.271:9): avc:  denied  { setfscreate } for  pid=522 comm="systemd-getty-g" scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:systemd_getty_generator_t:s0 tclass=process permissive=0
Jun 04 02:44:14 localhost kernel: audit: type=1400 audit(1717494254.271:10): avc:  denied  { setfscreate } for  pid=522 comm="systemd-getty-g" scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:systemd_getty_generator_t:s0 tclass=process permissive=0
Jun 04 02:44:15 localhost kernel: audit: type=1400 audit(1717494255.089:15): avc:  denied  { sendto } for  pid=570 comm="systemd-hwdb" path="/systemd/journal/socket" scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0
Jun 04 02:44:15 localhost kernel: audit: type=1400 audit(1717494255.089:16): avc:  denied  { write } for  pid=570 comm="systemd-hwdb" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=0
Jun 04 02:44:15 localhost audit[570]: AVC avc:  denied  { sendto } for  pid=570 comm="systemd-hwdb" path="/systemd/journal/socket" scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_dgram_socket permissive=0
Jun 04 02:44:15 localhost audit[570]: AVC avc:  denied  { write } for  pid=570 comm="systemd-hwdb" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=0
Jun 04 02:44:15 localhost audit[576]: AVC avc:  denied  { write } for  pid=576 comm="systemd-nsresou" name="memory.pressure" dev="cgroup2" ino=2767 scontext=system_u:system_r:systemd_nsresourced_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=file permissive=1
Jun 04 02:44:17 localhost audit[695]: AVC avc:  denied  { connectto } for  pid=695 comm="(emd-oomd)" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:17 localhost audit[696]: AVC avc:  denied  { connectto } for  pid=696 comm="(resolved)" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:17 localhost audit[765]: AVC avc:  denied  { connectto } for  pid=765 comm="(polkitd)" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:18 localhost audit[805]: AVC avc:  denied  { connectto } for  pid=805 comm="abrtd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:18 localhost audit[805]: AVC avc:  denied  { connectto } for  pid=805 comm="abrtd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:19 localhost.localdomain audit[854]: AVC avc:  denied  { connectto } for  pid=854 comm="(leshootd)" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:19 localhost.localdomain audit[854]: AVC avc:  denied  { connectto } for  pid=854 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:19 localhost.localdomain audit[730]: AVC avc:  denied  { connectto } for  pid=730 comm="auditd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:19 localhost.localdomain audit[854]: AVC avc:  denied  { connectto } for  pid=854 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:19 localhost.localdomain audit[730]: AVC avc:  denied  { connectto } for  pid=730 comm="auditd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:20 localhost.localdomain audit[854]: AVC avc:  denied  { connectto } for  pid=854 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:44:20 localhost.localdomain audit[854]: AVC avc:  denied  { connectto } for  pid=854 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:03 localhost.localdomain audit[936]: AVC avc:  denied  { connectto } for  pid=936 comm="login" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:03 localhost.localdomain audit[936]: AVC avc:  denied  { connectto } for  pid=936 comm="login" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:04 localhost.localdomain audit[1086]: AVC avc:  denied  { connectto } for  pid=1086 comm="(leshootd)" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:05 localhost.localdomain audit[1086]: AVC avc:  denied  { connectto } for  pid=1086 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:05 localhost.localdomain audit[1086]: AVC avc:  denied  { connectto } for  pid=1086 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:05 localhost.localdomain audit[1086]: AVC avc:  denied  { connectto } for  pid=1086 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0
Jun 04 02:49:05 localhost.localdomain audit[1086]: AVC avc:  denied  { connectto } for  pid=1086 comm="setroubleshootd" path="/run/systemd/io.systemd.NamespaceResource" scontext=system_u:system_r:setroubleshootd_t:s0 tcontext=system_u:system_r:systemd_nsresourced_t:s0 tclass=unix_stream_socket permissive=0

I lost the login prompt on serial console with update to selinux-policy-40.22-1.fc40.noarch

sudo dnf downgrade selinux-policy-targeted gives me selinux-policy-targeted-40.20-1.fc40.noarch which works fine.

Installing selinux-policy-40.23-1.fc40 and rebooting does not fix this, at least for me. The generator is still broken.

If I use audit2allow on these denials the resulting module allows the generator to work.
May 27 00:00:19 audit[1301]: AVC avc:  denied  { net_admin } for  pid=1301 comm="systemd-user-ru" capability=12  scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=capability permissive=1
type=AVC msg=audit(1718912889.274:568): avc:  denied  { search } for  pid=1430 comm="systemd-getty-g" name="1" dev="proc" ino=283 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1718912889.274:569): avc:  denied  { search } for  pid=1430 comm="systemd-getty-g" name="1" dev="proc" ino=283 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1718912889.274:570): avc:  denied  { net_admin } for  pid=1430 comm="systemd-getty-g" capability=12  scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:systemd_getty_generator_t:s0 tclass=capability permissive=0
type=AVC msg=audit(1718912889.275:571): avc:  denied  { search } for  pid=1430 comm="systemd-getty-g" name="1" dev="proc" ino=283 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1718912889.275:572): avc:  denied  { read write } for  pid=1430 comm="systemd-getty-g" name="ttyAMA10" dev="devtmpfs" ino=2 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0
type=AVC msg=audit(1718913666.811:560): avc:  denied  { read } for  pid=1474 comm="systemd-getty-g" name="cgroup" dev="proc" ino=5509 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=file permissive=0
type=AVC msg=audit(1718913666.818:561): avc:  denied  { read } for  pid=1474 comm="systemd-getty-g" name="environ" dev="proc" ino=5682 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=file permissive=0
type=AVC msg=audit(1718913666.818:562): avc:  denied  { read } for  pid=1474 comm="systemd-getty-g" name="environ" dev="proc" ino=5682 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=file permissive=0
type=AVC msg=audit(1718913666.818:563): avc:  denied  { ioctl } for  pid=1474 comm="systemd-getty-g" path="/dev/ttyAMA10" dev="devtmpfs" ino=2 ioctlcmd=0x5401 scontext=system_u:system_r:systemd_getty_generator_t:s0 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file permissive=0

The first only shows in the journal if I am in permssive mode. I guess it happens too early to be picked up in audit.log. The rest are from audit.log. 

I can alternatively manually enable serial-getty

I'm seeing the same issue on F-40 with a number of different arm devices.

Same on several VMs and machines with serial-attached IPMI consoles (all x86_64), although none of those cases emits any audit log entries.  Was scratching my head quite a bit before seeing the fedora-devel posts referencing this bug, especially since manually starting serial-getty@ttySx works fine.

I am still encountering this testing with Fedora 41 selinux-policy.

(In reply to Jason Montleon from comment #8)
> I am still encountering this testing with Fedora 41 selinux-policy.

So am I

Proposed as a Blocker for 41-beta by Fedora user pbrobinson using the blocker tracking app because:

 Need to be able to login on all supported mechanisms.

Created attachment 2038995 [details]
output of boot from starfive VF2 serial uart connection does not display login prompt after installing lastest f41 kernel

You are all SUPER-HEROES!

I just wanted to capture the starfive VisionFive 2 serial uart output displaying the boot output.
NOTE:  I can acknowledge there is not tty on the serial console.

Kernel 6.10.0-0.rc6.20240702git1dfe225e9af5.51.0.riscv64.fc41.riscv64 on an riscv64 (ttyS0)

I can also acknowledge adding enforcing=0 in the linux boot parameters and then enabling the serial getty service then rebooting gave me back the login prompt for the interim.
sudo systemctl enable --now serial-getty@ttyS0

Jason's VF2 6.9'ish kernel repo in association with koji f40 repo was ok for the serial terminal login.  I lost my serial terminal login after changing koji repo from f40 to f41, it upgraded not only the kernel, but all the f40 packages to f41 using davidlt's newer kernel 6.10.0-0rc6

This is Jason's repo in case you want a last known good for the vf2..

[vf2-lpi4a]
name=vf2-lpi4a
enabled=1
gpgcheck=0
baseurl=https://people.redhat.com/jmontleo/fedora/linux/releases/40/vf2-lpi4a/riscv64/

[vf2-lpi4a-source]
name=vf2-lpi4a-source
enabled=0
gpgcheck=0
baseurl=https://people.redhat.com/jmontleo/fedora/linux/releases/40/vf2-lpi4a/source/tree

(In reply to David Marceau from comment #11)
> Created attachment 2038995 [details]
> output of boot from starfive VF2 serial uart connection does not display login prompt after installing lastest f41 kernel

You have three AVCs in that attachment. This is the first one:

[   14.134067] audit: type=1400 audit(1719878409.335:4): avc:  denied  { getattr } for  pid=425 comm="systemd-fstab-g" path="/boot" dev="mmcblk1p5" ino=258 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir permissive=0

You might try relabeling:

# fixfiles onboot

or

# touch /.autorelabel

Doc: fixfiles (8)         - fix file SELinux security contexts.

(In reply to David Marceau from comment #11)
> Created attachment 2038995 [details]
> output of boot from starfive VF2 serial uart connection does not display login prompt after installing lastest f41 kernel

[    3.193361] 10000000.serial: ttyS0 at MMIO 0x10000000 (irq = 20, base_baud = 1500000) is a 16550A

That attachment doesn't show whether the systemd serial-getty is running. Try this:

$ systemctl status serial-getty

Created attachment 2039055 [details]
my relabel of the sdcard before rebooting

this is the just the output of what I could capture of the relabel of the sdcard before it rebooted.

Created attachment 2039056 [details]
output from the bootup after the relabel completed successfully

The attached file holds the output from the journalctl -b
after the relabel completed successfully and rebooted.

(In reply to Steve from comment #14)
> (In reply to David Marceau from comment #11)
> > Created attachment 2038995 [details]
> > output of boot from starfive VF2 serial uart connection does not display login prompt after installing lastest f41 kernel
> 
> [    3.193361] 10000000.serial: ttyS0 at MMIO 0x10000000 (irq = 20,
> base_baud = 1500000) is a 16550A
> 
> That attachment doesn't show whether the systemd serial-getty
> is running. Try this:
> 
> $ systemctl status serial-getty

After the relabeling and the reboot, I did as you requested.

[riscv@fedora-riscv ~]$ sudo systemctl status serial-getty
[sudo] password for riscv: 
● serial-getty - Serial Getty on ttyS0
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Thu 2024-07-04 23:33:48 EDT; 17min ago
 Invocation: 76b4ac92e66e487480b48d08ac77fedd
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 806 (agetty)
      Tasks: 1 (limit: 9453)
     Memory: 328K (peak: 6.5M)
        CPU: 96ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty
             └─806 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - vt220

Jul 04 23:33:48 fedora-riscv systemd[1]: serial-getty: Scheduled restart job, restart counter is at 1.
Jul 04 23:33:48 fedora-riscv systemd[1]: Started serial-getty - Serial Getty on ttyS0.
[riscv@fedora-riscv ~]$

Thanks for the (In reply to David Marceau from comment #16)
> Created attachment 2039056 [details] output from the bootup after the relabel completed successfully
> The attached file holds the output from the journalctl -b after the relabel completed successfully and rebooted.

Thanks for the update.

The AVCs have been cleared, serial-getty is starting normally, and you were able to login on ttyS0:

Jul 04 23:30:13 fedora-riscv login[707]: DIALUP AT ttyS0 BY root
Jul 04 23:30:13 fedora-riscv login[707]: ROOT LOGIN ON ttyS0

However, the log does not show the "Kernel command line" for the boot after relabeling, and the "enforcing=" record is missing.

Did you boot with selinux enforcing enabled?

$ getenforce

selinux-policy-41.7-1.fc41 could address some of the problems being reported here:
https://koji.fedoraproject.org/koji/packageinfo?packageID=32

(In reply to Steve from comment #19)
> selinux-policy-41.7-1.fc41 could address some of the problems being reported here:
> https://koji.fedoraproject.org/koji/packageinfo?packageID=32

That hasn't been pushed, because it failed a lot of tests:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-64134f8805

However, I have been testing it with F41 Workstation in a VM.

Connecting to ttyS0 with the "virsh" "console" command works as expected.

To test, download selinux-policy and selinux-policy-targeted from Koji:
https://koji.fedoraproject.org/koji/buildinfo?buildID=2480699

Install with:
$ sudo dnf install ./selinux*.rpm

Huh, looks like I missed that update failing tests, probably because it landed during a long weekend here. It's failing tests because it breaks Apache (and hence FreeIPA). https://bodhi.fedoraproject.org/updates/FEDORA-2024-64134f8805#comment-3600824

selinux-policy-40.23-1.fc40 with a relabel doesn't seem to fix it on a RPi4, I will test on some other devices.

Can someone reference the upstream commit that fixed it so I can possibly debug some more?

Upstream is here, but we won't know if this bug is fixed with selinux-policy-41.7-1 until it is tested by users with real serial ports (as opposed to ones in a VM):

https://github.com/fedora-selinux/selinux-policy

See the changelog too:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2480699

With an F40 Server in a VM and connected with "virsh console", there are no serious problems:

$ tty
/dev/ttyS0

$ sudo ausearch -i -ts boot -m avc
<no matches>

There are, however, these log messages:

$ journalctl --no-hostname -b -g credentials
Jul 05 16:12:04 agetty[751]: failed to open credentials directory
Jul 05 16:12:04 agetty[752]: failed to open credentials directory

$ rpm -q selinux-policy
selinux-policy-40.23-1.fc40.noarch

$ rpm -qf /usr/sbin/agetty
util-linux-core-2.40.1-1.fc40.x86_64

$ uname -r
6.9.7-200.fc40.x86_64

> https://github.com/fedora-selinux/selinux-policy

I meant what was the PR that apparently fixed this bug?

(In reply to Peter Robinson from comment #25)
> > https://github.com/fedora-selinux/selinux-policy
> 
> I meant what was the PR that apparently fixed this bug?

We don't know that this bug is fixed on bare metal.

In a VM, the serial port works fine.

What do you show for these?

$ sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts boot

$ journalctl --no-hostname -b -g credentials

(I'm assuming that ssh is working.)

(In reply to Steve from comment #26)
> $ journalctl --no-hostname -b -g credentials

This is a better diagnostic:

$ systemctl status serial-getty

(In reply to Peter Robinson from comment #25)
> I meant what was the PR that apparently fixed this bug?

If you are asking what is the latest released version of selinux-policy, you can find it listed here:
https://bodhi.fedoraproject.org/updates/?packages=selinux-policy

For F40, "dnf update" should get it.

For 41, you have to use the manual process described in Comment 20.

I am using the latest Fedora 40 package and I still have this issue. I've tried a relabel with no change.

$ rpm -q selinux-policy selinux-policy-targeted
selinux-policy-40.23-1.fc40.noarch
selinux-policy-targeted-40.23-1.fc40.noarch

I have already mentioned most of this in https://bugzilla.redhat.com/show_bug.cgi?id=2290482#c5 but:

You need to run `semodule -DB`, reboot, and look in the journal to see the first denials.
ausearch won't show them. I have attached output with denials from my journal. You'll see denials for fstab, zram, bless_boot, and getty generators. The start of the getty issues are here. If you add a module to fix the getty generator denial you'll start seeing errors in audit.log that present later in boot.

You can boot with enforcing=0, or manually enable the getty with systemctl enable --now serial-getty@tty... but one should not have to do either of these.

(In reply to Jason Montleon from comment #30)
...
> You need to run `semodule -DB`, reboot, and look in the journal to see the first denials.
> ausearch won't show them.
...

Thanks for the tips. Apparently the kernel logs denials before auditd starts running.

However, in an F40 Workstation VM with selinux-policy-41.7-1.fc41.noarch, there are very few of those:

$ journalctl --no-hostname -b | fgrep avc
Jul 05 22:10:08 kernel: audit: type=1400 audit(1720242608.182:7): avc:  denied  { write } for  pid=510 comm="systemd-integri" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:systemd_generic_generator_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1
Jul 05 22:10:08 kernel: audit: type=1400 audit(1720242608.182:8): avc:  denied  { open } for  pid=510 comm="systemd-integri" path="/dev/kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:systemd_generic_generator_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=1
Jul 05 22:10:08 kernel: audit: type=1400 audit(1720242608.194:9): avc:  denied  { write } for  pid=504 comm="systemd-cryptse" name="kmsg" dev="devtmpfs" ino=10 scontext=system_u:system_r:systemd_cryptsetup_generator_t:s0 tcontext=system_u:object_r:kmsg_device_t:s0 tclass=chr_file permissive=0
Jul 05 22:10:08 kernel: audit: type=1400 audit(1720242608.468:10): avc:  denied  { write } for  pid=544 comm="systemd-journal" name="memory.pressure" dev="cgroup2" ino=2041 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=file permissive=0
...

(In reply to Steve from comment #31)
...
> However, in an F40 Workstation VM with selinux-policy-41.7-1.fc41.noarch, there are very few of those:
...

And ttyS0 is running and functional after booting:

$ systemctl -q list-units serial-getty
  serial-getty loaded active running Serial Getty on ttyS0

So I suggest installing selinux-policy-41.7-1.fc41.noarch on an F40 system per Comment 20.

(In reply to Peter Robinson from comment #25)
> > https://github.com/fedora-selinux/selinux-policy
> 
> I meant what was the PR that apparently fixed this bug?

There isn't one, nor any reason to believe there is.

Just one confused individual celebrating success at booting a system with enforcing=0 and a manually enabled getty (comment 11), and another incessantly spamming this bug with completely irrelevant noise.

Meanwhile, the "maintainer" is pulling the usual routine of playing AVC whack-a-mole, claiming to have fixed something after one attempt, and ghosting the bug thereafter, ignoring all further evidence to the contrary.  There's no reason to believe this is going to improve, either.

(In reply to Rob Foehl from comment #33)

Please see section 4 of the Red Hat Terms of Use:
https://www.redhat.com/en/about/terms-use

I tried selinux-policy-41.7-1.fc41

It does appear to clean up some of the generator denials in the journal, but the serial getty is still not started automatically unless I boot with enforcing=0.

With this version I see some similarity to
https://github.com/coreos/fedora-coreos-tracker/issues/1735
https://bugzilla.redhat.com/show_bug.cgi?id=2290482

The linked issue points to this as a fix, which from inspection appears to be included in selinux-policy-41.7-1.fc41, but as noted on the coreos issue and BZ it does not appear to have resolved the problem.
https://github.com/fedora-selinux/selinux-policy/pull/1979 

I am having a difficult time seeing the denial(s) causing the issue.

I have to stop for now, but I'll continue to dig when time permits.

This is sufficient to get a working console. It looks like systemd_getty_generator_t is missing access to the character device file.

```
module custom-agetty 1.0;

require {
	type tty_device_t;
	type systemd_getty_generator_t;
	class chr_file { ioctl read write };
}

#============= systemd_getty_generator_t ==============
allow systemd_getty_generator_t tty_device_t:chr_file { ioctl read write };
```

If someone else wants to confirm:
- Confirm workarounds are removed, selinux is enforcing, serial-getty service disabled, booting to no console login. 
- Place the contents above in a file `custom-agetty.te`
- Ensure you have selinux-policy-devel installed
- make -f /usr/share/selinux/devel/Makefile custom-agetty.pp
- semodule -i custom-agetty.pp
- reboot

To remove the custom module:
- semodule -r custom-agetty

I tested with selinux-policy-targeted-40.23-1.fc40.noarch and selinux-policy-targeted-41.7-1.fc41.noarch (https://koji.fedoraproject.org/koji/buildinfo?buildID=2480699) and had success with both.

> With this version I see some similarity to
> https://github.com/coreos/fedora-coreos-tracker/issues/1735
> https://bugzilla.redhat.com/show_bug.cgi?id=2290482
> 
I inadvertently linked back to this bug. That should have been
https://bugzilla.redhat.com/show_bug.cgi?id=2292472

(In reply to Jason Montleon from comment #36)
...
> - Confirm workarounds are removed, selinux is enforcing, serial-getty service disabled, booting to no console login. 
...

Thanks for your detailed instructions. Could you clarify this: "serial-getty service disabled"?

In systemd terminology, I believe we want the serial-getty service *enabled*, but for the failure-reproducer, we want to verify that the serial-getty service is not "active" after booting. This systemctl command will show the state of all the systemd units matching the pattern:

$ systemctl list-units -a serial-getty\*

"The ACTIVE column [in the output] shows the general unit state, one of active, reloading, inactive, failed, activating, deactivating." (systemctl (1))

BTW, you can use "autolinkification" to link to other Bugzilla bugs by typing the literal string "Bug xxxxxxx".
Comments can also linked: "Bug xxxxxxx, Comment yy".
https://bugzilla.redhat.com/docs/en/html/using/tips.html

It is trivial to work around this issue, even if the generator is not working properly. 

You can just:
```
$ sudo systemctl enable --now serial-getty@ttyS0
Created symlink /etc/systemd/system/getty.target.wants/serial-getty → /usr/lib/systemd/system/serial-getty@.service.
```

But with the generator you're not supposed to require the link; this really should not have to exist.
/etc/systemd/system/getty.target.wants/serial-getty

Disabling the service just removes the link and the state we want to function.
$ sudo systemctl disable --now serial-getty@ttyS0
Removed "/etc/systemd/system/getty.target.wants/serial-getty".


When the generator works properly notice it states `enabled-runtime` instead of `enabled`:
```
# systemctl status serial-getty 
● serial-getty - Serial Getty on ttyS0
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-03-20 20:00:28 EDT; 3 months 16 days ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 745 (agetty)
      Tasks: 1 (limit: 9461)
     Memory: 472.0K (peak: 6.1M)
        CPU: 102ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty
             └─745 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - vt220
```

vs. `enabled` when manually enabling the service and relying on the link.

```
# systemctl status serial-getty 
● serial-getty - Serial Getty on ttyS0
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-03-20 20:00:27 EDT; 3 months 16 days ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 740 (agetty)
      Tasks: 1 (limit: 9461)
     Memory: 472.0K (peak: 6.3M)
        CPU: 105ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty
             └─740 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - vt220
```

The problem is not very difficult to work around if you are aware of the issue. However, when unsuspecting users flash an sd card for a raspberry pi, visionfive 2, or some other arm or riscv SBC and are relying on serial to configuring it then just appears to freeze after booting, before they have a chance to log in. They don't have ssh or whatever to fall back on at this point. This is roughly what happened to David Marceau when trying to boot a VisionFive 2. I was aware of the issue, happened to see the conversation, and helped walk him through getting logged in.

Reading up at https://www.freedesktop.org/wiki/Software/systemd/Generators/

I can confirm if the generator is working you will see that the unit file is created here instead:
/run/systemd/generator/getty.target.wants/serial-getty

Jason: Thanks for the detailed explanation. That explains why I cannot reproduce the problem in my VMs.

In my VMs I always do this:

$ sudo systemctl enable --now serial-getty

So, for anyone who just wants a workaround before the problem is fixed, run the above command.

Of course, ssh needs to be working, as you suggest. Or connect a monitor and USB keyboard, if the SBC supports them.

As for how the generator "knows" to generate the service, the device must already exist:

$ journalctl --no-hostname -b | fgrep ttyS0
Jul 06 21:09:31 kernel: 00:00: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

(In reply to Steve from comment #41)
> That explains why I cannot reproduce the problem in my VMs.

Maybe not.

After running:

# systemctl disable --now serial-getty

And booting in permissive mode:

$ getenforce
Permissive

And verifying that the ttyS0 device exists:

$ journalctl --no-hostname -b | fgrep ttyS0
Jul 06 23:13:49 kernel: 00:00: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A

$ file /dev/ttyS0
/dev/ttyS0: character special (4/64)

The serial-getty unit is not auto-generated:

$ systemctl list-units -a serial-getty\*
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

And there or no messages related to agetty:

$ journalctl --no-hostname -b | fgrep agetty

There must be something else different between a VM and an SBC.

Tested with F40 Workstation in a VM, fully updated.

$ rpm -q selinux-policy systemd
selinux-policy-41.7-1.fc41.noarch
systemd-255.8-1.fc40.x86_64

kernel 6.9.7-200.fc40.x86_64

$ ll -Z /usr/lib/systemd/system-generators/systemd-getty-generator
-rwxr-xr-x. 1 root root system_u:object_r:systemd_getty_generator_exec_t:s0 24440 Jun 28 17:00 /usr/lib/systemd/system-generators/systemd-getty-generator

From https://0pointer.de/blog/projects/serial-console.html

Add console=ttyS0 to the kernel command line.

You can make it permanent by editing GRUB_CMDLINE_LINUX in /etc/default/grub. If you do it before updating the system it will be applied automatically for you when the kernel is updated without the need to run anything manually.

Otherwise you can probably run:
grubby --update-kernel=ALL --args="console=ttyS0"

From then on in an x86_64 VM the behavior matches what I have described including workarounds and fixes.

I believe you have to do this in an x86_64 virtual machine because:
"By default systemd will instantiate one serial-getty@.service on the main kernel[4] console, if it is not a virtual terminal."

[4] "If multiple kernel consoles are used simultaneously, the main console is the one listed first in /sys/class/tty/console/active, which is the last one listed on the kernel command line."

Without looking, because I deleted the VM already I am guessing on an x86_64 VM the display vt is the main kernel console. Adding console=ttyS0 probably makes it the main console instead.

Jason: Thanks for researching that. I never would have figured that out. :-)

The log actually shows the difference: tty0 vs ttyS0:

Without console=ttyS0 on the kernel command-line:

$ journalctl --no-hostname -b -1 | fgrep 'legacy console'
Jul 07 07:05:57 kernel: printk: legacy console [tty0] enabled

With console=ttyS0 on the kernel command-line:

$ journalctl --no-hostname -b | fgrep 'legacy console'
Jul 07 09:06:15 kernel: printk: legacy console [ttyS0] enabled

In the latter case, I can now almost reproduce what you reported in Comment 39:

$ sudo setenforce 0

$ getenforce
Permissive

$ sudo systemctl daemon-reload # "This will rerun all generators ..." (systemctl(1))

$ systemctl list-units -a serial-getty\*
  UNIT                       LOAD   ACTIVE   SUB  DESCRIPTION          
  serial-getty loaded inactive dead Serial Getty on ttyS0
...

This shows "enabled-runtime":

$ systemctl status serial-getty
○ serial-getty - Serial Getty on ttyS0
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html

Tested with an F40 VM (x86_64) and no custom selinux policies:

$ rpm -q selinux-policy systemd
selinux-policy-40.23-1.fc40.noarch
systemd-255.8-1.fc40.x86_64

$ uname -r
6.9.7-200.fc40.x86_64

With enforcing=0 and console=ttyS0 on the kernel command-line, I can reproduce in a VM what you reported in Comment 39:

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.9.7-200.fc40.x86_64 root=UUID=3d655a0e-4b35-4a73-bf51-da06a6de53ab ro enforcing=0 console=ttyS0

$ getenforce
Permissive

$ systemctl list-units -a serial-getty\*
  UNIT                       LOAD   ACTIVE SUB     DESCRIPTION          
  serial-getty loaded active running Serial Getty on ttyS0
...

This shows "enabled-runtime":

$ systemctl status serial-getty
● serial-getty - Serial Getty on ttyS0
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2024-07-07 10:02:06 PDT; 36s ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 863 (agetty)
      Tasks: 1 (limit: 9462)
     Memory: 448.0K (peak: 6.2M)
        CPU: 13ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty
             └─863 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - vt220

Jul 07 10:02:06 fedora-xfce-1 systemd[1]: Started serial-getty - Serial Getty on ttyS0.
Jul 07 10:02:06 fedora-xfce-1 agetty[863]: failed to open credentials directory

> In the latter case, I can now almost reproduce what you reported in Comment
> 39:
> 
> $ sudo setenforce 0
> 
> $ getenforce
> Permissive
> 
> $ sudo systemctl daemon-reload # "This will rerun all generators ..."
> (systemctl(1))
> 
> $ systemctl list-units -a serial-getty\*
>   UNIT                       LOAD   ACTIVE   SUB  DESCRIPTION          
>   serial-getty loaded inactive dead Serial Getty on ttyS0
> ...
> 
> This shows "enabled-runtime":
> 
> $ systemctl status serial-getty
> ○ serial-getty - Serial Getty on ttyS0

I don't follow. Doesn't this show exactly what we have reported? You put the system in permissive mode and reloaded the daemon. This is supposed to work on boot in enforcing mode. You're not supposed to have to put the system in permissive mode.

Full video reproducer from install to fix. You can watch the entire thing, or jump; times for important events are in the description.

https://www.youtube.com/watch?v=XWfZY-l-D7k

(In reply to Jason Montleon from comment #47)
...
> > $ systemctl list-units -a serial-getty\*
> >   UNIT                       LOAD   ACTIVE   SUB  DESCRIPTION          
> >   serial-getty loaded inactive dead Serial Getty on ttyS0
...

> I don't follow. Doesn't this show exactly what we have reported? You put the system in permissive mode and reloaded the daemon.

In Comment 45, I said "almost reproduce" only because the service was "inactive" and "dead".

The essential point is that the service was "enabled-runtime", which means that the generator ran.

I didn't think to try actually starting the service.

> This is supposed to work on boot in enforcing mode.

With your fix, which I was not testing.

> You're not supposed to have to put the system in permissive mode.

I was not verifying a fix but confirming a failure-reproducer, which entails two steps:

1. Boot with enforcing enabled and note that the serial-getty unit is not loaded. This is documented in previous comments.

2. Boot with enforcing disabled (permissive mode) and verify that the unit is loaded and running. This is documented in Comment 46.

From that, we can only deduce that an selinux fix is needed.

The next step would be to test your fix.

Testing with VMs is extremely useful, so when there is a difference in the behavior between a VM and a bare metal install, it is essential to understand why.

Thanks for all your help with this.

(In reply to Jason Montleon from comment #48)
> Full video reproducer from install to fix. You can watch the entire thing, or jump; times for important events are in the description.
> 
> https://www.youtube.com/watch?v=XWfZY-l-D7k

I watched the whole thing, except that I skipped over the familiar parts. :-)

This clearly affects Fedora 40 too, so retargeting. (Initially filed a separate bug in https://bugzilla.redhat.com/show_bug.cgi?id=2296652 before finding this one.)

*** Bug 2296652 has been marked as a duplicate of this bug. ***

Is this issue still in place with selinux-policy-40.23-1.fc40.noarch or selinux-policy-41.7-1.fc41.noarch?
Note policy in F40 and F41 is now quite different regarding systemd.
This bz was reported for F41, we'd rather continue with yours for F40 if still needed.

(In reply to Zdenek Pytela from comment #53)
> Is this issue still in place with selinux-policy-40.23-1.fc40.noarch

Yes. That version is in the latest testing-devel builds and the bug can still be reproduced there: https://builds.coreos.fedoraproject.org/browser?stream=testing-devel&arch=x86_64

> or selinux-policy-41.7-1.fc41.noarch?

Yes. I see the following denials:

Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.729:3): avc:  denied  { map_read map_write } for  pid=751 comm="bootc-systemd-g" scontext=system_u:system_r:systemd_generic_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.733:4): avc:  denied  { map_read map_write } for  pid=756 comm="kdump-dep-gener" scontext=system_u:system_r:kdump_dep_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.734:5): avc:  denied  { map } for  pid=754 comm="coreos-liveiso-" path="/usr/bin/bash" dev="vda4" ino=3032099 scontext=system_u:system_r:systemd_generic_generator_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.734:6): avc:  denied  { execute } for  pid=754 comm="coreos-liveiso-" path="/usr/bin/bash" dev="vda4" ino=3032099 scontext=system_u:system_r:systemd_generic_generator_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.734:7): avc:  denied  { map_read map_write } for  pid=753 comm="coreos-installe" scontext=system_u:system_r:coreos_installer_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.738:8): avc:  denied  { map_read map_write } for  pid=760 comm="selinux-autorel" scontext=system_u:system_r:selinux_autorelabel_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.739:9): avc:  denied  { map_read map_write } for  pid=761 comm="systemd-bless-b" scontext=system_u:system_r:systemd_bless_boot_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1
Jul 09 18:20:57 localhost kernel: audit: type=1400 audit(1720549256.740:10): avc:  denied  { map_read map_write } for  pid=762 comm="systemd-cryptse" scontext=system_u:system_r:systemd_cryptsetup_generator_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=bpf permissive=1

but oddly, none of them seem like it's from systemd-getty-generator.

That version is not in the latest FCOS rawhide builds (https://builds.coreos.fedoraproject.org/browser?stream=rawhide&arch=x86_64), but you can download the latest there, boot it with `coreos-assembler run -c` but add `--kargs enforcing=0` to work around the bug, then `rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2024-64134f8805` to test it.

> Note policy in F40 and F41 is now quite different regarding systemd.
> This bz was reported for F41, we'd rather continue with yours for F40 if
> still needed.

Sure, WFM.

All of these are either fixed somewhere (selinux-policy, systemd) or will be with
https://bugzilla.redhat.com/show_bug.cgi?id=2292472

Any other problem like no getty on a serial console?

Right, to be clear, that's still the main problem even though there's no denial entry for it. I was merely showing the denials that *do* show up.

So I suppose

setenforce 0

makes the service working. What will be audited when dontaudit rules are disabled?

semodule -DB

Any entry in journal? What if you triggered generators?

systemctl daemon-reload

With 40.23 and 41.7 still have to add this.

Without access to the character device file the unit file is not created/started by the generator and there is no login prompt on serial without manual workarounds.

module custom-agetty 1.0;

require {
	type tty_device_t;
	type systemd_getty_generator_t;
	class chr_file { ioctl read write };
}

#============= systemd_getty_generator_t ==============
allow systemd_getty_generator_t tty_device_t:chr_file { ioctl read write };

Created attachment 2039351 [details]
Output of `journalctl -b 0 --grep avc --no-pager` on selinux-policy-41.7-1.fc41

For completeness, I've attached the full list of the denials. The ones mentioning getty are:

```
$ grep getty selinux-policy-41.7-1.fc41-denials.log
Jul 09 19:59:11 localhost.localdomain audit[1108]: AVC avc:  denied  { noatsecure } for  pid=1108 comm="gensnippet_if" scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:getty_t:s0 tclass=process permissive=1
Jul 09 19:59:11 localhost.localdomain audit[1108]: AVC avc:  denied  { rlimitinh } for  pid=1108 comm="agetty" scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:getty_t:s0 tclass=process permissive=1
Jul 09 19:59:11 localhost.localdomain audit[1108]: AVC avc:  denied  { siginh } for  pid=1108 comm="agetty" scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:getty_t:s0 tclass=process permissive=1
Jul 09 19:59:11 localhost.localdomain audit[1070]: AVC avc:  denied  { checkpoint_restore } for  pid=1070 comm="agetty" capability=40  scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=capability2 permissive=1
Jul 09 19:59:21 localhost.localdomain audit[1070]: AVC avc:  denied  { noatsecure } for  pid=1070 comm="agetty" scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=process permissive=1
Jul 09 19:59:21 localhost.localdomain audit[1070]: AVC avc:  denied  { read write } for  pid=1070 comm="login" path="socket:[10160]" dev="sockfs" ino=10160 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tclass=netlink_route_socket permissive=1
Jul 09 19:59:21 localhost.localdomain audit[1070]: AVC avc:  denied  { rlimitinh } for  pid=1070 comm="login" scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=process permissive=1
Jul 09 19:59:21 localhost.localdomain audit[1070]: AVC avc:  denied  { siginh } for  pid=1070 comm="login" scontext=system_u:system_r:getty_t:s0-s0:c0.c1023 tcontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tclass=process permissive=1
```

(In reply to Zdenek Pytela from comment #57)
> So I suppose
> 
> setenforce 0
> 
> makes the service working. What will be audited when dontaudit rules are
> disabled?
> 
> semodule -DB
> 
> Any entry in journal? What if you triggered generators?
> 
> systemctl daemon-reload

Yes, disabling dontaudit rules is a prerequisite.  There's plenty of detail in comment 36.

Why is this so difficult?  Same pattern of behavior, bug after bug.

Zdenek: additionally, I'm not sure you realize this: selinux-policy-41.7-1.fc41 is not in Rawhide. It failed gating because it (still) breaks FreeIPA. I reported this at https://bodhi.fedoraproject.org/updates/FEDORA-2024-64134f8805#comment-3600824 . The current version in Rawhide is selinux-policy-41.3-1.fc41 . You need to fix the FreeIPA issues to get a new build into Rawhide.

I'm not sure if selinux-policy-41.8-1.fc41.noarch is supposed to have fixed this bug or not, but it doesn't:

https://bodhi.fedoraproject.org/updates/FEDORA-2024-2711625691

In a clean install of F41 in a VM with:

$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.10.0-0.rc7.58.fc41.x86_64 root=UUID=975cca99-7a74-4bf7-a8ad-5e5050cc6a55 ro rootflags=subvol=root console=ttyS0

$ getenforce
Enforcing

There are no AVCs:

$ journalctl --no-hostname -b | egrep -i 'legacy console|avc'
Jul 10 07:39:48 kernel: printk: legacy console [ttyS0] enabled

Yet serial-getty had to be started manually:

$ sudo systemctl start serial-getty

(In reply to Steve from comment #62)
> I'm not sure if selinux-policy-41.8-1.fc41.noarch is supposed to have fixed this bug or not, but it doesn't:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-2711625691
...

I just realized that "this bug" concerns openQA tests of FreeIPA and that those tests with selinux-policy-41.8-1.fc41.noarch appear to have passed.

So, ISTM, we need:

1. A new bug report concerning auto-generation of serial-getty.

2. An openQA test for auto-generation of serial-getty.

(In reply to Adam Williamson from comment #0)
> The openQA serial console install test started failing in Fedora-Rawhide-20240601.n.0. This turns out to be an SELinux policy issue.
...

Adam: Could you please include a link to the actual openQA test suite in which there was a failure?

The whiteboard says "openqa", so there should really be a link to tests relevant to this bug report.

https://openqa.fedoraproject.org/tests/2720061

(In reply to Adam Williamson from comment #65)
> https://openqa.fedoraproject.org/tests/2720061

Thanks, Adam. Very interesting.

So the "_console_wait_login" test failed with Fedora-Rawhide-20240709.n.0.

I looked at every log and couldn't find the version of selinux-policy that was tested. This is the best that I could find:

"Installing selinux-policy.noarch (467/617)"
https://openqa.fedoraproject.org/tests/2720061/logfile?filename=serial_terminal_user.txt

The version is, however, in the logs under ./var/log/anaconda/ in the tarball:
https://openqa.fedoraproject.org/tests/2720061/file/_console_wait_login-var_log.tar.gz

$ fgrep selinux-policy ./var/log/anaconda/lorax-packages.log
selinux-policy-41.3-1.fc41.noarch
selinux-policy-targeted-41.3-1.fc41.noarch

For anyone who wants to follow along:

selinux-policy updates:
https://bodhi.fedoraproject.org/updates/?packages=selinux-policy

Fedora nightly compose finder (These appear to be the same as the images that are tested with openQA.):
https://openqa.fedoraproject.org/nightlies.html

Summary log of openQA test for "install_serial_console":
https://openqa.fedoraproject.org/tests/2720061#next_previous

(In reply to Steve from comment #66)
...
> Fedora nightly compose finder (These appear to be the same as the images that are tested with openQA.):
> https://openqa.fedoraproject.org/nightlies.html
...

They are indeed the same. Even better, if you put your pointer over a red link (meaning a test for that image failed), you get a list of links to the actual tests that failed. Very nice!

selinux-policy-41.9-1.fc41 restores auto-generation of serial-getty:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-3510bbb1bb

$ systemctl show --property=UnitFileState serial-getty
UnitFileState=enabled-runtime

Tested in an F41 Server VM with:

$ cat /proc/cmdline 
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.10.0-64.fc41.x86_64 root=UUID=e94b97ba-d791-45cf-85cf-925c1de42ce8 ro console=ttyS0

I don't know what the plan is for an F40 update, but progress can be tracked at these links:

Builds:
https://koji.fedoraproject.org/koji/packageinfo?packageID=32

Updates:
https://bodhi.fedoraproject.org/updates/?packages=selinux-policy

Reposting from Bug 2298080, which is explicitly listed under the "Bugs" tab:

FEDORA-2024-391cfa58c2 (selinux-policy-40.25-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-391cfa58c2

selinux-policy-40.26-1.fc40 fixes Bug 2298080:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f6d12d5c36

Auto-generation of serial-getty works as expected.

Procedure:

Boot F40 VM with "console=ttyS0" on the kernel command-line.

In virt-manager VM window, select "View:Consoles:Serial 1" and login.

$ tty
/dev/ttyS0

$ systemctl show --property UnitFileState serial-getty
UnitFileState=enabled-runtime

Tested with:

systemd-255.8-1.fc40.x86_64
kernel 6.9.10-200.fc40.x86_64

This is fixed for Rawhide since Fedora-Rawhide-20240719.n.1 . Dropping it as an F41 blocker.

FEDORA-2024-995d585c91 (selinux-policy-40.27-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-995d585c91

FEDORA-2024-995d585c91 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-995d585c91`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-995d585c91

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-995d585c91 (selinux-policy-40.27-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.