Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250 comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow: allow sysctl_irq_t proc_t:filesystem associate;
As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/
Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM).
1. dev_manage.fc: ------------------------------ /sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0)
2. dev_manage.te ------------------------------ module dev_manage 1.0;
type dev_manage_t;
require { type bin_t; type sysctl_irq_t;
class file { search read write getattr open }; class dir { search read write getattr open }; }
allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open };
Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much.
- Gilboa
On Sun, 2016-12-18 at 21:11 +0200, Gilboa Davara wrote:
Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250
comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow:
allow sysctl_irq_t proc_t:filesystem associate;
filesystem associate permission is only check for: - mount with context= option, - file creation, - relabeling of a file.
None of those make sense for /proc/irq/* files AFAIK.
What is your script doing to trigger this denial? /proc files are kernel-generated pseudo files, so they aren't files that userspace would be creating or relabeling.
As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/
Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM).
- dev_manage.fc:
/sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0)
- dev_manage.te
module dev_manage 1.0;
type dev_manage_t;
require { type bin_t; type sysctl_irq_t;
class file { search read write getattr open }; class dir { search read write getattr open }; }
allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open };
Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much.
- Gilboa
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
On Wed, Dec 21, 2016 at 10:10 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Sun, 2016-12-18 at 21:11 +0200, Gilboa Davara wrote:
Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250
comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow:
allow sysctl_irq_t proc_t:filesystem associate;
filesystem associate permission is only check for:
- mount with context= option,
- file creation,
- relabeling of a file.
None of those make sense for /proc/irq/* files AFAIK.
What is your script doing to trigger this denial? /proc files are kernel-generated pseudo files, so they aren't files that userspace would be creating or relabeling.
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
- Gilboa
As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/
Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM).
- dev_manage.fc:
/sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0)
- dev_manage.te
module dev_manage 1.0;
type dev_manage_t;
require { type bin_t; type sysctl_irq_t;
class file { search read write getattr open }; class dir { search read write getattr open };}
allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open };
Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much.
- Gilboa
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org
On Sat, 2016-12-24 at 12:04 +0200, Gilboa Davara wrote:
On Wed, Dec 21, 2016 at 10:10 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Sun, 2016-12-18 at 21:11 +0200, Gilboa Davara wrote:
Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250
comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow:
allow sysctl_irq_t proc_t:filesystem associate;
filesystem associate permission is only check for:
- mount with context= option,
- file creation,
- relabeling of a file.
None of those make sense for /proc/irq/* files AFAIK.
What is your script doing to trigger this denial? /proc files are kernel-generated pseudo files, so they aren't files that userspace would be creating or relabeling.
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
The only scenario where we would expect to see that denial is if /proc/irq/XXX/smp_affinity did not exist and it tried to create it as a result. No point in allowing that; it can't be done anyway.
On Mon, Jan 9, 2017 at 11:54 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
The only scenario where we would expect to see that denial is if /proc/irq/XXX/smp_affinity did not exist and it tried to create it as a result. No point in allowing that; it can't be done anyway.
The IRQ entries are valid, so does smp_affinity. If the IRQ management script is called from a root console, I get no denials. If the IRQ management script is called by a systemd service, I get denials.
The denial message is: "type=AVC msg=audit(1483384972.624:3669): avc: denied { associate } for pid=10271 comm="ipp_start" name="smp_affinity" scontext=system_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0" ipp_start label is unconfined_u:object_r:bin_t:s0.
I was planning to write a policy file, as I assumed it was intentional systemd-related-policy. Am I wrong?
- Gilboa
On Tue, 2017-01-17 at 18:39 +0200, Gilboa Davara wrote:
On Mon, Jan 9, 2017 at 11:54 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
The only scenario where we would expect to see that denial is if /proc/irq/XXX/smp_affinity did not exist and it tried to create it as a result. No point in allowing that; it can't be done anyway.
The IRQ entries are valid, so does smp_affinity. If the IRQ management script is called from a root console, I get no denials. If the IRQ management script is called by a systemd service, I get denials.
The denial message is: "type=AVC msg=audit(1483384972.624:3669): avc: denied { associate } for pid=10271 comm="ipp_start" name="smp_affinity" scontext=system_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0" ipp_start label is unconfined_u:object_r:bin_t:s0.
I was planning to write a policy file, as I assumed it was intentional systemd-related-policy. Am I wrong?
There is no benefit in allowing it in policy; you can't create files there. You can dontaudit it if you want to suppress the log noise.
On Tue, Jan 17, 2017 at 7:11 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Tue, 2017-01-17 at 18:39 +0200, Gilboa Davara wrote:
On Mon, Jan 9, 2017 at 11:54 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
The only scenario where we would expect to see that denial is if /proc/irq/XXX/smp_affinity did not exist and it tried to create it as a result. No point in allowing that; it can't be done anyway.
The IRQ entries are valid, so does smp_affinity. If the IRQ management script is called from a root console, I get no denials. If the IRQ management script is called by a systemd service, I get denials.
The denial message is: "type=AVC msg=audit(1483384972.624:3669): avc: denied { associate } for pid=10271 comm="ipp_start" name="smp_affinity" scontext=system_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0" ipp_start label is unconfined_u:object_r:bin_t:s0.
I was planning to write a policy file, as I assumed it was intentional systemd-related-policy. Am I wrong?
There is no benefit in allowing it in policy; you can't create files there. You can dontaudit it if you want to suppress the log noise.
Hello Stephen,
Thanks again for taking the time to answer me questions. I appreciate the effort.
The log message are annoying but not the main issue, the main problem that SELinux seems to block my script from configuring smp_affinity from within a systemd service. I'll be eternally grateful if you can point me at the right direction how to give my script the SELinux attributes required to configure smp_affinity from a systemd service domain.
- Gilboa
On Fri, 2017-01-20 at 13:07 +0200, Gilboa Davara wrote:
On Tue, Jan 17, 2017 at 7:11 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Tue, 2017-01-17 at 18:39 +0200, Gilboa Davara wrote:
On Mon, Jan 9, 2017 at 11:54 PM, Stephen Smalley <sds@tycho.nsa.g ov> wrote:
Hello,
Sorry for the late reply. Was AFK for a couple of days. The script is used to attach certain network device IRQ to specific CPUs using 'echo XXXX > /proc/irq/XXX/smp_affinity'.
The only scenario where we would expect to see that denial is if /proc/irq/XXX/smp_affinity did not exist and it tried to create it as a result. No point in allowing that; it can't be done anyway.
The IRQ entries are valid, so does smp_affinity. If the IRQ management script is called from a root console, I get no denials. If the IRQ management script is called by a systemd service, I get denials.
The denial message is: "type=AVC msg=audit(1483384972.624:3669): avc: denied { associate } for pid=10271 comm="ipp_start" name="smp_affinity" scontext=system_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0" ipp_start label is unconfined_u:object_r:bin_t:s0.
I was planning to write a policy file, as I assumed it was intentional systemd-related-policy. Am I wrong?
There is no benefit in allowing it in policy; you can't create files there. You can dontaudit it if you want to suppress the log noise.
Hello Stephen,
Thanks again for taking the time to answer me questions. I appreciate the effort.
The log message are annoying but not the main issue, the main problem that SELinux seems to block my script from configuring smp_affinity from within a systemd service. I'll be eternally grateful if you can point me at the right direction how to give my script the SELinux attributes required to configure smp_affinity from a systemd service domain.
What other avc denials are you getting? The one you've listed so far isn't meaningful.
Have you confirmed that it works correctly if you make SELinux permissive (i.e. is it truly SELinux that is preventing it from working)?
On Fri, Jan 20, 2017 at 4:04 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Fri, 2017-01-20 at 13:07 +0200, Gilboa Davara wrote:
Hello Stephen,
Thanks again for taking the time to answer me questions. I appreciate the effort.
The log message are annoying but not the main issue, the main problem that SELinux seems to block my script from configuring smp_affinity from within a systemd service. I'll be eternally grateful if you can point me at the right direction how to give my script the SELinux attributes required to configure smp_affinity from a systemd service domain.
What other avc denials are you getting? The one you've listed so far isn't meaningful.
Have you confirmed that it works correctly if you make SELinux permissive (i.e. is it truly SELinux that is preventing it from working)?
Dropping to 'setenforce 0' removes the SELinux errors and the script seem to execute faster (by an order of magnitude). The weird thing is that even in enforcing mode, the script does manage to write the correct smp_affinity value, it simply takes it a couple of retries.
- Gilboa
On Tue, 2017-01-24 at 19:40 +0200, Gilboa Davara wrote:
On Fri, Jan 20, 2017 at 4:04 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Fri, 2017-01-20 at 13:07 +0200, Gilboa Davara wrote:
Hello Stephen,
Thanks again for taking the time to answer me questions. I appreciate the effort.
The log message are annoying but not the main issue, the main problem that SELinux seems to block my script from configuring smp_affinity from within a systemd service. I'll be eternally grateful if you can point me at the right direction how to give my script the SELinux attributes required to configure smp_affinity from a systemd service domain.
What other avc denials are you getting? The one you've listed so far isn't meaningful.
Have you confirmed that it works correctly if you make SELinux permissive (i.e. is it truly SELinux that is preventing it from working)?
Dropping to 'setenforce 0' removes the SELinux errors and the script seem to execute faster (by an order of magnitude). The weird thing is that even in enforcing mode, the script does manage to write the correct smp_affinity value, it simply takes it a couple of retries.
Ok, so what avc messages do you get when you run the script in permissive? If you aren't seeing any others, then retry after running semodule -DB, and then run semodule -B afterward.
On Sun, 2016-12-18 at 21:11 +0200, Gilboa Davara wrote:
Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250
comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow:
allow sysctl_irq_t proc_t:filesystem associate;
As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/
Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM).
- dev_manage.fc:
/sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0)
- dev_manage.te
module dev_manage 1.0;
type dev_manage_t;
require { type bin_t; type sysctl_irq_t;
class file { search read write getattr open }; class dir { search read write getattr open }; }
allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open };
Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much.
You need to define a domain type (for the process) and a file type (for the executable file). Using an existing .te file is often a good way to go, or you could try using sepolicy generate. Is your script run as a service or by an admin user? That affects what domain transitions you need to set up for it.
On Wed, Dec 21, 2016 at 10:35 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Sun, 2016-12-18 at 21:11 +0200, Gilboa Davara wrote:
Hello all,
I've got a script that sets the network device IRQ CPU affinity. (irqbalance without the balance...). Due to changes to /proc/irq/XXX/* SELinux targeted policy (?) this script no longer works.
- avc message:: avc: denied { associate } for pid=234250
comm="dev_irq_fix" name="smp_affinity" scontext=unconfined_u:object_r:sysctl_irq_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
- audit2allow:
allow sysctl_irq_t proc_t:filesystem associate;
As I appreciate the need of solid SELinux policy I rather label my script correctly, as opposed to opening the sysctl_irq_t gate to world+dog. As such, I'd like to create a file label that *extends* the generic bin_t label - lets call it dev_manage_t - and will be used to give a certain set of scripts the ability to modify /proc/irq/XXX/
Now, I tried creating the following policy, and needless to say it failed, miserably, when I tried to restorecon my script files (EPERM).
- dev_manage.fc:
/sbin/dev_irq_set -- gen_context(unconfined_u:object_r:dev_manage_t,s0) /sbin/dev_irq_fix -- gen_context(unconfined_u:object_r:dev_manage_t,s0)
- dev_manage.te
module dev_manage 1.0;
type dev_manage_t;
require { type bin_t; type sysctl_irq_t;
class file { search read write getattr open }; class dir { search read write getattr open };}
allow dev_manage_t sysctl_irq_t:file { search read write getattr open }; allow dev_manage_t sysctl_irq_t:dir { search read write getattr open };
Can anyone please point me to the right direction? I tried using exiting .te files as reference (E.g. irabalance.te) but it didn't help much.
You need to define a domain type (for the process) and a file type (for the executable file). Using an existing .te file is often a good way to go
I tried looking up the existing irqbalance te file, but it didn't help. Do you have any good / relevant examples?
, or you could try using sepolicy generate. Is your script run as a service or by an admin user? That affects what domain transitions you need to set up for it.
The script is run both by root and by systemd.
- Gilboa
selinux@lists.fedoraproject.org
-
Gilboa Davara -
Stephen Smalley