Error while running setsebool

[Geert Janssens]

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 ?

[Vit Mojzis]

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(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Geert Janssens]

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

[justina colmena ~biz]

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(a)kobaltwit.be&gt; 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(a)lists.fedoraproject.org
> To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
> 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.

[Michael Reilly]

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(a)kobaltwit.be&gt; 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(a)lists.fedoraproject.org
>      To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>      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(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
-- 
---- ---- ----
Michael Reilly    michaelr(a)cisco.com
     Cisco Systems   Arizona

[Geert Janssens]

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

[justina colmena ~biz]

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(a)kobaltwit.be&gt; 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.

[Vit Mojzis]

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(a)kobaltwit.be&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to selinux-leave(a)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/[e-mail]...
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure