Trying to set context on a FIFO for nut_upsmon_t process

[Robert Nichols]

SELinux is not allowing me to set the needed context on a FIFO that will be written by a nut_upsmon_t process. Runnin sesearch to find suitable types yields:
   allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open read write };
But, when I try to run "chcon -t nut_upsmon_t /path/to/fifo" I get "permission denied" and an SELinux alert than complains
   If you want to change the label of .alertFIFO2 to nut_upsmon_t, you are not allowed to since it is not a valid file type.
   Then you must pick a valid file label.
   Do
   select a valid file type.  List valid file labels by executing: 
   # seinfo -afile_type -x
That returns info for files, not FIFOs.

Once again, SELinux is causing me more problems than any virus would.

[Henry Zhang]

Robert,

If your application fails due to selinux policy, you could check
/var/log/audit/audit.log.
If the audit.log contains denial, please post or attach the log here.
It should show what kind of policy your application needed in order to
execute it.

---henry

On Thu, Jun 8, 2023 at 12:03 PM Robert Nichols 
wrote:
> SELinux is not allowing me to set the needed context on a FIFO that will
> be written by a nut_upsmon_t process. Runnin sesearch to find suitable
> types yields:
>    allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock
> open read write };
> But, when I try to run "chcon -t nut_upsmon_t /path/to/fifo" I get
> "permission denied" and an SELinux alert than complains
>    If you want to change the label of .alertFIFO2 to nut_upsmon_t, you are
> not allowed to since it is not a valid file type.
>    Then you must pick a valid file label.
>    Do
>    select a valid file type.  List valid file labels by executing:
>    # seinfo -afile_type -x
> That returns info for files, not FIFOs.
>
> Once again, SELinux is causing me more problems than any virus would.
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Robert Nichols]

On 6/8/23 16:12, Henry Zhang wrote:
> Robert,
>
> If your application fails due to selinux policy, you could check /var/log/audit/audit.log.
> If the audit.log contains denial, please post or attach the log here.
> It should show what kind of policy your application needed in order to execute it.
>
> ---henry

Since you asked, see below. I really don't want to allow a nut_upsmon_t process to write to any user_tmp_t file. That's adding unnecessary privilege. The right solution is to give the FIFO a label that allows the access. I used sesearch to find out what target types would be appropriate, and found:

allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open read write };

Note that the error is for "getattr", not "write". The script is checking that the name refers to a FIFO before writing to it. The same problem would occur for a "write" attempt.

chcon fails when trying to set that context on the FIFO, and when it tries I see a message that nut_upsmon_t is not a valid file type. What is it, then? Perhaps valid on a FIFO but not on an ordinary file?? The above "allow" rule shows what I need, but there is no way to set it.

SELinux is preventing /usr/bin/bash from getattr access on the fifo_file /tmp/.alertFIFO2.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that bash should be allowed getattr access on the .alertFIFO2 fifo_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'UPS-alert' --raw | audit2allow -M my-UPSalert
# semodule -X 300 -i my-UPSalert.pp

Additional Information:
Source Context                system_u:system_r:nut_upsmon_t:s0
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                /tmp/.alertFIFO2 [ fifo_file ]
Source                        UPS-alert
Source Path                   /usr/bin/bash
Port                          <Unknown>
Host                          omega-3x.local
Source RPM Packages
Target RPM Packages
SELinux Policy RPM            selinux-policy-targeted-3.14.3-117.el8.noarch
Local Policy RPM              selinux-policy-targeted-3.14.3-117.el8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     omega-3x.local
Platform                      Linux omega-3x.local 4.18.0-477.13.1.el8_8.x86_64
                               #1 SMP Tue May 30 22:15:39 UTC 2023 x86_64 x86_64
Alert Count                   4
First Seen                    2023-06-08 16:32:07 CDT
Last Seen                     2023-06-08 16:32:17 CDT
Local ID                      87bfa152-e72e-4bff-872e-2ccd882f0d48

Raw Audit Messages
type=AVC msg=audit(1686259937.20:17430): avc:  denied  { getattr } for  pid=860169 comm="UPS-alert" path="/tmp/.alertFIFO2" dev="tmpfs" ino=19804366 scontext=system_u:system_r:nut_upsmon_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=0

Hash: UPS-alert,nut_upsmon_t,user_tmp_t,fifo_file,getattr

[Henry Zhang]

Robert,

based on your audit.log message, the new policy should be
allow nut_upsmon_t user_tmp_t:fifo_file getattr

your policy:
allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open
read write };

destination type should be user_tmp_t instead of nut_upsmon_t

Normally, after updating your policy, your operation should go through

---henry

On Thu, Jun 8, 2023 at 2:49 PM Robert Nichols 
wrote:
> On 6/8/23 16:12, Henry Zhang wrote:
> > Robert,
> >
> > If your application fails due to selinux policy, you could check
>
> /var/log/audit/audit.log.
> > If the audit.log contains denial, please post or attach the log here.
> > It should show what kind of policy your application needed in order to
>
> execute it.
> > ---henry
>
> Since you asked, see below. I really don't want to allow a nut_upsmon_t
> process to write to any user_tmp_t file. That's adding unnecessary
> privilege. The right solution is to give the FIFO a label that allows the
> access. I used sesearch to find out what target types would be appropriate,
> and found:
> allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock
>
> open read write };
>
> Note that the error is for "getattr", not "write". The script is checking
> that the name refers to a FIFO before writing to it. The same problem would
> occur for a "write" attempt.
>
> chcon fails when trying to set that context on the FIFO, and when it tries
> I see a message that nut_upsmon_t is not a valid file type. What is it,
> then? Perhaps valid on a FIFO but not on an ordinary file?? The above
> "allow" rule shows what I need, but there is no way to set it.
>
> SELinux is preventing /usr/bin/bash from getattr access on the fifo_file
> /tmp/.alertFIFO2.
>
> *****  Plugin catchall (100. confidence) suggests
>
> If you believe that bash should be allowed getattr access on the
> .alertFIFO2 fifo_file by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'UPS-alert' --raw | audit2allow -M my-UPSalert
> # semodule -X 300 -i my-UPSalert.pp
>
> Additional Information:
> Source Context                system_u:system_r:nut_upsmon_t:s0
> Target Context                unconfined_u:object_r:user_tmp_t:s0
> Target Objects                /tmp/.alertFIFO2 [ fifo_file ]
> Source                        UPS-alert
> Source Path                   /usr/bin/bash
> Port                          <Unknown>
> Host                          omega-3x.local
> Source RPM Packages
> Target RPM Packages
> SELinux Policy RPM            selinux-policy-targeted-3.14.3-117.el8.noarch
> Local Policy RPM              selinux-policy-targeted-3.14.3-117.el8.noarch
> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                     omega-3x.local
> Platform                      Linux omega-3x.local
> 4.18.0-477.13.1.el8_8.x86_64
>                                #1 SMP Tue May 30 22:15:39 UTC 2023 x86_64
> x86_64
> Alert Count                   4
> First Seen                    2023-06-08 16:32:07 CDT
> Last Seen                     2023-06-08 16:32:17 CDT
> Local ID                      87bfa152-e72e-4bff-872e-2ccd882f0d48
>
> Raw Audit Messages
> type=AVC msg=audit(1686259937.20:17430): avc:  denied  { getattr } for
> pid=860169 comm="UPS-alert" path="/tmp/.alertFIFO2" dev="tmpfs"
> ino=19804366 scontext=system_u:system_r:nut_upsmon_t:s0
> tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=0
>
> Hash: UPS-alert,nut_upsmon_t,user_tmp_t,fifo_file,getattr
>
> --
> Bob Nichols     "NOSPAM" is really part of my email address.
>                  Do NOT delete it.
>
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Henry Zhang]

Robert,

Also if you set selinux to be permissive=1. Your application will go
through and you may get a group of denied messages in your
/var/log/audit/audit.log one time.
Then you update your policy based on the audit.log and set selinux back to
enforce mode (permissive=0)

---henry

On Fri, Jun 9, 2023 at 8:49 AM Henry Zhang  wrote:
> Robert,
>
> based on your audit.log message, the new policy should be
> allow nut_upsmon_t user_tmp_t:fifo_file getattr
>
> your policy:
> allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open
> read write };
>
> destination type should be user_tmp_t instead of nut_upsmon_t
>
> Normally, after updating your policy, your operation should go through
>
> ---henry
>
> On Thu, Jun 8, 2023 at 2:49 PM Robert Nichols 
> wrote:
> > On 6/8/23 16:12, Henry Zhang wrote:
> > > Robert,
> > >
> > > If your application fails due to selinux policy, you could check
> >
> > /var/log/audit/audit.log.
> > > If the audit.log contains denial, please post or attach the log here.
> > > It should show what kind of policy your application needed in order to
> >
> > execute it.
> > > ---henry
> >
> > Since you asked, see below. I really don't want to allow a nut_upsmon_t
> > process to write to any user_tmp_t file. That's adding unnecessary
> > privilege. The right solution is to give the FIFO a label that allows the
> > access. I used sesearch to find out what target types would be appropriate,
> > and found:
> > allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock
> >
> > open read write };
> >
> > Note that the error is for "getattr", not "write". The script is checking
> > that the name refers to a FIFO before writing to it. The same problem would
> > occur for a "write" attempt.
> >
> > chcon fails when trying to set that context on the FIFO, and when it
> > tries I see a message that nut_upsmon_t is not a valid file type. What is
> > it, then? Perhaps valid on a FIFO but not on an ordinary file?? The above
> > "allow" rule shows what I need, but there is no way to set it.
> >
> > SELinux is preventing /usr/bin/bash from getattr access on the fifo_file
> > /tmp/.alertFIFO2.
> >
> > *****  Plugin catchall (100. confidence) suggests
> >
> > If you believe that bash should be allowed getattr access on the
> > .alertFIFO2 fifo_file by default.
> > Then you should report this as a bug.
> > You can generate a local policy module to allow this access.
> > Do
> > allow this access for now by executing:
> > # ausearch -c 'UPS-alert' --raw | audit2allow -M my-UPSalert
> > # semodule -X 300 -i my-UPSalert.pp
> >
> > Additional Information:
> > Source Context                system_u:system_r:nut_upsmon_t:s0
> > Target Context                unconfined_u:object_r:user_tmp_t:s0
> > Target Objects                /tmp/.alertFIFO2 [ fifo_file ]
> > Source                        UPS-alert
> > Source Path                   /usr/bin/bash
> > Port                          <Unknown>
> > Host                          omega-3x.local
> > Source RPM Packages
> > Target RPM Packages
> > SELinux Policy RPM
> > selinux-policy-targeted-3.14.3-117.el8.noarch
> > Local Policy RPM
> > selinux-policy-targeted-3.14.3-117.el8.noarch
> > Selinux Enabled               True
> > Policy Type                   targeted
> > Enforcing Mode                Enforcing
> > Host Name                     omega-3x.local
> > Platform                      Linux omega-3x.local
> > 4.18.0-477.13.1.el8_8.x86_64
> >                                #1 SMP Tue May 30 22:15:39 UTC 2023 x86_64
> > x86_64
> > Alert Count                   4
> > First Seen                    2023-06-08 16:32:07 CDT
> > Last Seen                     2023-06-08 16:32:17 CDT
> > Local ID                      87bfa152-e72e-4bff-872e-2ccd882f0d48
> >
> > Raw Audit Messages
> > type=AVC msg=audit(1686259937.20:17430): avc:  denied  { getattr } for
> > pid=860169 comm="UPS-alert" path="/tmp/.alertFIFO2" dev="tmpfs"
> > ino=19804366 scontext=system_u:system_r:nut_upsmon_t:s0
> > tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=fifo_file permissive=0
> >
> > Hash: UPS-alert,nut_upsmon_t,user_tmp_t,fifo_file,getattr
> >
> > --
> > Bob Nichols     "NOSPAM" is really part of my email address.
> >                  Do NOT delete it.
> >
> > selinux mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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, report it:
> > https://pagure.io/fedora-infrastructure/new_issue

[Robert Nichols]

First, note that the existing policy's "allow" rule is not something I wrote. It is in the nut-2.8.0-3.el8.x86_64.rpm package. It is a complete mystery to me how a policy could allow those types of access to a type that is not a valid file type.

Second, opening up the permissions of nut_upsmon_t to write to user_tmp_t is precisely what I said I do _not_ want to do.

The solution I found (see my response to Trevor Hemsley) is to change the context of the FIFO to "initctl_t. That is one of the few fifo_file types that nut_upsmon_t is allowed to access. No change needed to the policy.

[Trevor Hemsley]

Hi

You appear to be running an el8 (clone) and on my Rocky Linux 8 system I ran

[root@rhel8 ~]# semanage fcontext -l | grep nut_
/etc/ups(/.*)?                                     all files          
system_u:object_r:nut_conf_t:s0
/sbin/upsdrvctl                                    regular file       
system_u:object_r:nut_upsdrvctl_exec_t:s0
/usr/lib/systemd/system/nut.*                      regular file       
system_u:object_r:nut_unit_file_t:s0
/usr/sbin/blazer_usb                               regular file       
system_u:object_r:nut_upsdrvctl_exec_t:s0
/usr/sbin/upsd                                     regular file       
system_u:object_r:nut_upsd_exec_t:s0
/usr/sbin/upsdrvctl                                regular file       
system_u:object_r:nut_upsdrvctl_exec_t:s0
/usr/sbin/upsmon                                   regular file       
system_u:object_r:nut_upsmon_exec_t:s0
/var/run/nut(/.*)?                                 all files          
system_u:object_r:nut_var_run_t:s0

I am wondering if your problem would just go away if you moved your FIFO 
under /var/run/nut where it would automatically be assigned nut_var_run_t

Or not! :-)

Trevor

On 08/06/2023 20:03, Robert Nichols wrote:
> SELinux is not allowing me to set the needed context on a FIFO that will be written by a nut_upsmon_t process. Runnin sesearch to find suitable types yields:
>     allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open read write };
> But, when I try to run "chcon -t nut_upsmon_t /path/to/fifo" I get "permission denied" and an SELinux alert than complains
>     If you want to change the label of .alertFIFO2 to nut_upsmon_t, you are not allowed to since it is not a valid file type.
>     Then you must pick a valid file label.
>     Do
>     select a valid file type.  List valid file labels by executing:
>     # seinfo -afile_type -x
> That returns info for files, not FIFOs.
>
> Once again, SELinux is causing me more problems than any virus would.
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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, report it: https://pagure.io/fedora-infrastructure/new_issue

[Robert Nichols]

Thanks for your suggestion, but this FIFO is for passing messages back to a program running in my desktop session to display notifications via dbus. My user program would not be able to access anything in /var/run nut. Also, it does not appear that the existing policy allows nut_upsmon_t to write to a nut_var_run_t:fifo_file.

# ls -ld /var/run nut
     drwxrwx---. 2 root dialout 140 2023-06-02 22:48:02 /var/run/nut

# sesearch -A -s nut_upsmon_t -p write | grep fifo_file
     allow daemon crond_t:fifo_file { append getattr ioctl lock read write };
     allow daemon initrc_domain:fifo_file { append getattr ioctl lock read write };
     allow daemon initrc_transition_domain:fifo_file { append getattr ioctl lock read write };
     allow domain abrt_t:fifo_file { append getattr ioctl lock read write };
     allow domain crond_t:fifo_file { append getattr ioctl lock read write };
     allow domain rpm_script_tmp_t:fifo_file { append getattr ioctl lock read write };
     allow domain rpm_transition_domain:fifo_file { append getattr ioctl lock read write };
     allow domain sshd_t:fifo_file { append getattr ioctl lock read write };
     allow domain system_cronjob_t:fifo_file { append getattr ioctl lock read write };
     allow domain var_run_t:fifo_file write;
     allow nut_upsmon_t initctl_t:fifo_file { append getattr ioctl lock open read write };
     allow nut_upsmon_t nut_upsmon_t:fifo_file { append create getattr ioctl link lock open read rename setattr unlink write }; [ fips_mode ]:True
     allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock open read write };
     allow nut_upsmon_t systemd_passwd_var_run_t:fifo_file { append create getattr ioctl link lock open read rename setattr unlink write };

But, I have found a solution in that sesearch output. Running "chcon -t initctl_t .alertFIFO" allows the nut_upsmon_t process to use the FIFO, and my unconfined user process can read from it.

[Henry Zhang]

Robert,

You can use following command to find out which policy you are missing
audit2allow -r -i /var/log/audit/audit.log > new_policy.txt

---henry

On Fri, Jun 9, 2023 at 10:00 AM Robert Nichols 
wrote:
> Thanks for your suggestion, but this FIFO is for passing messages back to
> a program running in my desktop session to display notifications via dbus.
> My user program would not be able to access anything in /var/run nut. Also,
> it does not appear that the existing policy allows nut_upsmon_t to write to
> a nut_var_run_t:fifo_file.
>  # ls -ld /var/run nut
>  drwxrwx---. 2 root dialout 140 2023-06-02 22:48:02 /var/run/nut
>
>  # sesearch -A -s nut_upsmon_t -p write | grep fifo_file
>  allow daemon crond_t:fifo_file { append getattr ioctl lock read write
>
> };
>      allow daemon initrc_domain:fifo_file { append getattr ioctl lock read
> write };
>      allow daemon initrc_transition_domain:fifo_file { append getattr
> ioctl lock read write };
>      allow domain abrt_t:fifo_file { append getattr ioctl lock read write
> };
>      allow domain crond_t:fifo_file { append getattr ioctl lock read write
> };
>      allow domain rpm_script_tmp_t:fifo_file { append getattr ioctl lock
> read write };
>      allow domain rpm_transition_domain:fifo_file { append getattr ioctl
> lock read write };
>      allow domain sshd_t:fifo_file { append getattr ioctl lock read write
> };
>      allow domain system_cronjob_t:fifo_file { append getattr ioctl lock
> read write };
>      allow domain var_run_t:fifo_file write;
>      allow nut_upsmon_t initctl_t:fifo_file { append getattr ioctl lock
> open read write };
>      allow nut_upsmon_t nut_upsmon_t:fifo_file { append create getattr
> ioctl link lock open read rename setattr unlink write }; [ fips_mode ]:True
>      allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl lock
> open read write };
>      allow nut_upsmon_t systemd_passwd_var_run_t:fifo_file { append create
> getattr ioctl link lock open read rename setattr unlink write };
>
> But, I have found a solution in that sesearch output. Running "chcon -t
> initctl_t .alertFIFO" allows the nut_upsmon_t process to use the FIFO, and
> my unconfined user process can read from it.
>
> --
> Bob Nichols     "NOSPAM" is really part of my email address.
>                  Do NOT delete it.
>
> On 6/9/23 11:03, Trevor Hemsley wrote:
> > Hi
> >
> > You appear to be running an el8 (clone) and on my Rocky Linux 8 system I
>
> ran
> > [root@rhel8 ~]# semanage fcontext -l | grep nut_
> > /etc/ups(/.*)?                                     all files
>
> system_u:object_r:nut_conf_t:s0
> > /sbin/upsdrvctl                                    regular file
>
> system_u:object_r:nut_upsdrvctl_exec_t:s0
> > /usr/lib/systemd/system/nut.*                      regular file
>
> system_u:object_r:nut_unit_file_t:s0
> > /usr/sbin/blazer_usb                               regular file
>
> system_u:object_r:nut_upsdrvctl_exec_t:s0
> > /usr/sbin/upsd                                     regular file
>
> system_u:object_r:nut_upsd_exec_t:s0
> > /usr/sbin/upsdrvctl                                regular file
>
> system_u:object_r:nut_upsdrvctl_exec_t:s0
> > /usr/sbin/upsmon                                   regular file
>
> system_u:object_r:nut_upsmon_exec_t:s0
> > /var/run/nut(/.*)?                                 all files
>
> system_u:object_r:nut_var_run_t:s0
> > I am wondering if your problem would just go away if you moved your FIFO
>
> under /var/run/nut where it would automatically be assigned nut_var_run_t
> > Or not! :-)
> >
> > Trevor
> >
> > On 08/06/2023 20:03, Robert Nichols wrote:
> > > SELinux is not allowing me to set the needed context on a FIFO that
>
> will be written by a nut_upsmon_t process. Runnin sesearch to find suitable
> types yields:
> > > allow nut_upsmon_t nut_upsmon_t:fifo_file { append getattr ioctl
>
> lock open read write };
> > > But, when I try to run "chcon -t nut_upsmon_t /path/to/fifo" I get
>
> "permission denied" and an SELinux alert than complains
> > > If you want to change the label of .alertFIFO2 to nut_upsmon_t, you
>
> are not allowed to since it is not a valid file type.
> > > Then you must pick a valid file label.
> > > Do
> > > select a valid file type.  List valid file labels by executing:
> > > # seinfo -afile_type -x
> > >
> > > That returns info for files, not FIFOs.
> > >
> > > Once again, SELinux is causing me more problems than any virus would.
> > > _______________________________________________
> > > selinux mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
> > selinux mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
>
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue