2:03 p.m.
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.
4:12 p.m.
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 <rbtnichols(a)fedoraproject.org>
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 -- 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/selinux@lists.fedoraproject...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
4:49 p.m.
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.
10:49 a.m.
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 <rnicholsNOSPAM(a)comcast.net>
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 -- 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/selinux@lists.fedoraproject...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
11:02 a.m.
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 <henryzhang62(a)gmail.com> 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 <rnicholsNOSPAM(a)comcast.net>
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 -- 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/selinux@lists.fedoraproject...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
12:16 p.m.
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.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
On 6/9/23 10:49, 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 <rnicholsNOSPAM(a)comcast.net
<mailto:rnicholsNOSPAM@comcast.net>> 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 -- selinux(a)lists.fedoraproject.org
<mailto:selinux@lists.fedoraproject.org>
To unsubscribe send an email to selinux-leave(a)lists.fedoraproject.org
<mailto:selinux-leave@lists.fedoraproject.org>
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
List Archives:
https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject...
<https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
<https://pagure.io/fedora-infrastructure/new_issue>
_______________________________________________
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/selinux@lists.fedoraproject...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
11:03 a.m.
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 -- 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/selinux@lists.fedoraproject...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
noon
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 -- 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/selinux@lists.fedoraproject...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
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/selinux@lists.fedoraproject...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
12:13 p.m.
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 <rnicholsNOSPAM(a)comcast.net>
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 -- 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/selinux@lists.fedoraproject...
>> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
> _______________________________________________
> 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/selinux@lists.fedoraproject...
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
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/selinux@lists.fedoraproject...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
384
days inactive
385
days old
selinux@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Henry Zhang -
Robert Nichols -
Robert Nichols -
Trevor Hemsley