Bug 2156633

can you also confirm it would work having policy extended with:

--- a/radicale.te
+++ b/radicale.te
@@ -1,8 +1,10 @@
-policy_module(radicale, 1.0.9)
+policy_module(radicale, 1.0.10)
 
 gen_require(`
     type httpd_t;
     type pop_port_t;
+    type sysfs_t; # RHBZ#2156633
+    type init_t; # RHBZ#2156633
 ')
 
 ########################################
@@ -45,6 +47,10 @@ allow radicale_t self:unix_dgram_socket create_stream_socket_perms;
 allow radicale_t radicale_port_t:tcp_socket name_bind;
 allow radicale_t pop_port_t:tcp_socket name_connect;
 
+allow radicale_t sysfs_t:file { read open }; # RHBZ#2156633
+
+allow init_t radicale_exec_t:file ioctl; # RHBZ#2156633
+
 manage_dirs_pattern(radicale_t, radicale_log_t, radicale_log_t)
 manage_files_pattern(radicale_t, radicale_log_t, radicale_log_t)
 manage_lnk_files_pattern(radicale_t, radicale_log_t, radicale_log_t)



Can't currently build a new package as kinit on FEDORAPROJECT.ORG is currently not working, hopefully only a transient issue.

Please try this build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2105444 and report result

Hello Peter,

I did the following:
- created a new KVM VM
- installed f37 server (Fedora-Server-dvd-x86_64-37-1.7.iso)
- updated all packages
- rebooted
- installed the radicale packages from your build
- copied my working radicale config files and collections to system
- opened port 5232/tcp
- started radicale server
- pointed my thunderbird at it

it seems to work. Thank you very much. I did see this SELinux message each time radicale starts:

-- start --
type=AVC msg=audit(1673301164.769:372): avc:  denied  { read } for  pid=1646 comm="radicale" name="net" dev="proc" ino=4026531845 scontext=system_u:system_r:radicale_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file permissive=0
-- end --

It seems not to be tragic, but I guess it would be nicer if no errors were associated with running radicale.

Cheers,
rob

Thank you for testing. I can't reproduce the SELinux message where it looks like that "radicale" want to access something in "/proc/net".

And I've tried on a vanilla F37 (same ISO like you) a fresh installation of current version radicale3-3.1.7-32.fc37.noarch and cannot even reproduce the initial problem (also not on EL8 btw).

Can you please check whether your issues also occurs with default config?

If not, what can be the particular differences, that even 3.1.7-32.fcf37 starts without any SELinux messages proper while your config/installation triggers some?

And how do you start "radicale"?

The default config only listens on localhost:5232. If you change this line in /etc/radicale/config from:

  #hosts = localhost:5232

to

  hosts = 0.0.0.0:5232

you will get the SELinux denial message. All other settings were the defaults.

I am using the default systemd service to start radicale.

Ok, doublechecked, test system fixed, missed the SElinux policy sub-RPM at all :-(

Please test https://koji.fedoraproject.org/koji/buildinfo?buildID=2109514

is a simple "dnf upgrade <list-of-packages>" sufficient, or should I go back to the snapshot I made before install the first set?

FEDORA-2023-281e2817d2 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-281e2817d2

(In reply to Robert Urban from comment #7)
> is a simple "dnf upgrade <list-of-packages>" sufficient, or should I go back
> to the snapshot I made before install the first set?

Update is published but usually takes one day until you can use "dnf" with enabling testing repository.

Meanwhile you can download and upgrade manually: https://koji.fedoraproject.org/koji/buildinfo?buildID=2109578

Note: it contains now also the long outstanding patch related to logging timestamp twice in case started by systemd

the question is whether I should roll back my VM to a snapshot I made before installing your first set of test packages, or if it will suffice to simply update to the new test packages. In other words, could a simple update cause the SELinux rules to be different compared to rolling back to a pristine VM snapshot and then installing the second set of test packages.

It is clear to me that I can download them using the link you provided.

you can simply update, no need to rollback to a snapshot

FEDORA-EPEL-2023-522a68fff0 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-522a68fff0

FEDORA-EPEL-2023-9aa658ad6e has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9aa658ad6e

FEDORA-EPEL-2023-522a68fff0 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-522a68fff0

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

FEDORA-EPEL-2023-9aa658ad6e has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9aa658ad6e

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

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

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

FEDORA-2023-5b36556d78 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5b36556d78

FEDORA-2023-06d9e90295 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-06d9e90295

I confirm that after upgrading using the packages here: https://koji.fedoraproject.org/koji/buildinfo?buildID=2109514 I no longer see the SELinux denied message. This was using the configuration that listens on 0.0.0.0:5232.

Would you like me to test anything else?

> I confirm that after upgrading using the packages here:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2109514 I no longer
> see the SELinux denied message. This was using the configuration that
> listens on 0.0.0.0:5232.

Thank you for confirmation!

> Would you like me to test anything else?

Nothing else required, the new release only extends SELinux policy, see below.

Beside that it has only 2 (simple) fixes included

suppress timestamp if started by systemd
https://github.com/Kozea/Radicale/pull/1276
 -> already verified by me, working well

support MOVE behind a reverse proxy
https://github.com/Kozea/Radicale/pull/1271
  -> already verified by me and others, working well


diff --git a/radicale.te b/radicale.te
index 60b0faf..4a219fb 100644
--- a/radicale.te
+++ b/radicale.te
@@ -1,8 +1,12 @@
-policy_module(radicale, 1.0.9)
+policy_module(radicale, 1.0.10)
 
 gen_require(`
     type httpd_t;
     type pop_port_t;
+    type sysfs_t; # RHBZ#2156633
+    type init_t; # RHBZ#2156633
+    type proc_net_t; # RHBZ#2156633
+    type sysctl_net_t; # RHBZ#2156633
 ')
 
 ########################################
@@ -45,6 +49,15 @@ allow radicale_t self:unix_dgram_socket create_stream_socket_perms;
 allow radicale_t radicale_port_t:tcp_socket name_bind;
 allow radicale_t pop_port_t:tcp_socket name_connect;
 
+allow radicale_t sysfs_t:file { read open }; # RHBZ#2156633
+
+allow init_t radicale_exec_t:file ioctl; # RHBZ#2156633
+
+allow radicale_t proc_net_t:lnk_file read; # RHBZ#2156633
+allow radicale_t proc_net_t:file read; # RHBZ#2156633
+allow radicale_t sysctl_net_t:dir search; # RHBZ#2156633
+allow radicale_t sysctl_net_t:file { read open getattr }; # RHBZ#2156633
+
 manage_dirs_pattern(radicale_t, radicale_log_t, radicale_log_t)
 manage_files_pattern(radicale_t, radicale_log_t, radicale_log_t)
 manage_lnk_files_pattern(radicale_t, radicale_log_t, radicale_log_t)

thank you very much for your effort.

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

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

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

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

FEDORA-EPEL-2023-522a68fff0 has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2023-9aa658ad6e has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-06d9e90295 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2023-5b36556d78 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.