Hi,
I have a minimal Fedora 35 box that's configured as a mail server. It started life as a Fedora 33 system and got upgraded to 35 yesterday in an attempt to fix the following error I was getting.
I am trying to set an selinux boolean using the following command:
setsebool -P rsync_client 1
This returns the following output: libsepol.context_from_record: type avahi_conf_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:avahi_conf_t:s0 to sid invalid context system_u:object_r:avahi_conf_t:s0 Failed to commit changes to booleans: Success
Aside from the last line being very confusing the boolean seems to be set but the setting won't persist across reboots. I suspect the error lines hint at the problem but a search on the net didn't reveal what's going on.
As mentioned this was already happening while the system was still Fedora 33 (though the undefined type then was something with dns). I hoped it would get fixed with an upgrade to Fedora 35, but it only changed the type that's undefined.
What's going on here and how can I solve this ?
On 03. 02. 22 14:35, Geert Janssens wrote:
Hi,
I have a minimal Fedora 35 box that's configured as a mail server. It started life as a Fedora 33 system and got upgraded to 35 yesterday in an attempt to fix the following error I was getting.
I am trying to set an selinux boolean using the following command:
setsebool -P rsync_client 1
This returns the following output: libsepol.context_from_record: type avahi_conf_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:avahi_conf_t:s0 to sid invalid context system_u:object_r:avahi_conf_t:s0 Failed to commit changes to booleans: Success
Aside from the last line being very confusing the boolean seems to be set but the setting won't persist across reboots. I suspect the error lines hint at the problem but a search on the net didn't reveal what's going on.
As mentioned this was already happening while the system was still Fedora 33 (though the undefined type then was something with dns). I hoped it would get fixed with an upgrade to Fedora 35, but it only changed the type that's undefined.
What's going on here and how can I solve this ?
Hi, could you please share which version of selinux-policy you are on and if you have any custom policy modules ("sudo semodule -lfull | grep -v 100")?
avahi_conf_t was only added recently (F34 I believe), which explains why you didn't see it before. Does policy rebuild work properly ("sudo semodule -B")? If not, does selinux-policy and selinux-policy-targeted reinstall do any difference?
Vit
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
Thank you for your reply. Your questions helped me find the source of the issue. There was indeed a custom module that had issues. I have simply removed it as it was written for a configuration I no longer use.
Regards,
Geert
Have you tried this?
# touch /.autorelabel && reboot
I've had to run this command every time a Fedora upgrade touches the kernel or SELinux policy, and it's neither automatic nor documented as a necessary step.
Right now I am using CentOS 7 on OpenVZ in the cloud, otherwise very similar to Fedora, but sadly SELinux is disabled on most if not all VM hosting services, and the KVM (keyboard-video-mouse) virtualization offered by some providers, which would potentially allow a customer to install and use any Linux distribution with SELinux enabled, is rife with virtualization-related Intel/AMD/x86 hardware and microcode bugs.
On February 3, 2022 4:35:07 AM AKST, Geert Janssens geert@kobaltwit.be wrote:
Hi,
I have a minimal Fedora 35 box that's configured as a mail server. It started life as a Fedora 33 system and got upgraded to 35 yesterday in an attempt to fix the following error I was getting.
I am trying to set an selinux boolean using the following command:
setsebool -P rsync_client 1
This returns the following output: libsepol.context_from_record: type avahi_conf_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:avahi_conf_t:s0 to sid invalid context system_u:object_r:avahi_conf_t:s0 Failed to commit changes to booleans: Success
Aside from the last line being very confusing the boolean seems to be set but the setting won't persist across reboots. I suspect the error lines hint at the problem but a search on the net didn't reveal what's going on.
As mentioned this was already happening while the system was still Fedora 33 (though the undefined type then was something with dns). I hoped it would get fixed with an upgrade to Fedora 35, but it only changed the type that's undefined.
What's going on here and how can I solve this ?
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
What symptoms do you see that require a relabel?
I keep up to date with patches so the kernel is updated fairly often.
I've never had to relabel in all of this time.
FWIW - Been running Fedora with selinux in enforcing mode since a version in the late teens (don't remember exactly which one). I last installed from scratch using rev 27. Been upgrading since then. I am about to upgrade to 35 from 33.
michael
On 2/4/22 06:57, justina colmena ~biz wrote:
Have you tried this?
# touch /.autorelabel && reboot
I've had to run this command every time a Fedora upgrade touches the kernel or SELinux policy, and it's neither automatic nor documented as a necessary step.
Right now I am using CentOS 7 on OpenVZ in the cloud, otherwise very similar to Fedora, but sadly SELinux is disabled on most if not all VM hosting services, and the KVM (keyboard-video-mouse) virtualization offered by some providers, which would potentially allow a customer to install and use any Linux distribution with SELinux enabled, is rife with virtualization-related Intel/AMD/x86 hardware and microcode bugs.
On February 3, 2022 4:35:07 AM AKST, Geert Janssens geert@kobaltwit.be wrote:
Hi, I have a minimal Fedora 35 box that's configured as a mail server. It started life as a Fedora 33 system and got upgraded to 35 yesterday in an attempt to fix the following error I was getting. I am trying to set an selinux boolean using the following command: setsebool -P rsync_client 1 This returns the following output: libsepol.context_from_record: type avahi_conf_t is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:avahi_conf_t:s0 to sid invalid context system_u:object_r:avahi_conf_t:s0 Failed to commit changes to booleans: Success Aside from the last line being very confusing the boolean seems to be set but the setting won't persist across reboots. I suspect the error lines hint at the problem but a search on the net didn't reveal what's going on. As mentioned this was already happening while the system was still Fedora 33 (though the undefined type then was something with dns). I hoped it would get fixed with an upgrade to Fedora 35, but it only changed the type that's undefined. What's going on here and how can I solve this ? -------------------------------------------------------------------------------- selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Op vrijdag 4 februari 2022 14:57:10 CET schreef justina colmena ~biz:
Have you tried this?
# touch /.autorelabel && reboot
I didn't exactly run that command but I remember running "restorecon -Rv /" which I believe should have the same effect. That didn't fix my issue and it possibly even printed errors on the console as well. With the help of Vit Mojzis I managed to fix the issue. The problem turned out to be a broken custom policy. I don't know what broke it but the system works properly now. So I can't go back to reproduce any details other than those I reported in a previous reply.
Regards,
Geert
The command "restorecon -Rv /" _should_ do the same thing as creating the file "/.autorelabel" and rebooting, but the risk to restoring contexts after the system has already booted is that the privileges necessary to restore certain security contexts may have been dropped already.
"setenforce 0" just sets a boolean, AFAIK. It depends on policy whether or not that does or should drop all SELinux enforcement mechanisms at runtime, but only the boot-time relabel is _guaranteed_ to restore _all_ system and user files to the "correct" security context according to the prescribed policy.
On February 5, 2022 12:34:30 AM AKST, Geert Janssens geert@kobaltwit.be wrote:
Op vrijdag 4 februari 2022 14:57:10 CET schreef justina colmena ~biz:
Have you tried this?
# touch /.autorelabel && reboot
I didn't exactly run that command but I remember running "restorecon -Rv /" which I believe should have the same effect. That didn't fix my issue and it possibly even printed errors on the console as well. With the help of Vit Mojzis I managed to fix the issue. The problem turned out to be a broken custom policy. I don't know what broke it but the system works properly now. So I can't go back to reproduce any details other than those I reported in a previous reply.
Regards,
Geert
On 05. 02. 22 11:06, justina colmena ~biz wrote:
The command "restorecon -Rv /" _should_ do the same thing as creating the file "/.autorelabel" and rebooting, but the risk to restoring contexts after the system has already booted is that the privileges necessary to restore certain security contexts may have been dropped already.
Even using /.autorelabel the system loads the security policy before relabeling, the only difference from manually executing restorecon/fixfiles is that the relabeling is performed in permissive mode (so running restorecon/fixfiles in permissive mode should have the same effect as /.autorelabel).
"setenforce 0" just sets a boolean, AFAIK. It depends on policy whether or not that does or should drop all SELinux enforcement mechanisms at runtime, but only the boot-time relabel is _guaranteed_ to restore _all_ system and user files to the "correct" security context according to the prescribed policy.
Not really. "Setenforce 0" (i.e. permissive mode) actually changes behaviour of SELinux regardless of the loaded security policy. The security policy is NOT enforced in permissive mode -- system calls not permitted by the policy will go through just fine and the policy violation will be logged.
On February 5, 2022 12:34:30 AM AKST, Geert Janssens geert@kobaltwit.be wrote:
Op vrijdag 4 februari 2022 14:57:10 CET schreef justina colmena ~biz: Have you tried this? # touch /.autorelabel && reboot I didn't exactly run that command but I remember running "restorecon -Rv /" which I believe should have the same effect. That didn't fix my issue and it possibly even printed errors on the console as well. With the help of Vit Mojzis I managed to fix the issue. The problem turned out to be a broken custom policy. I don't know what broke it but the system works properly now. So I can't go back to reproduce any details other than those I reported in a previous reply. Regards, Geert-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
selinux@lists.fedoraproject.org
-
Geert Janssens -
justina colmena ~biz -
Michael Reilly -
Vit Mojzis