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;

On Wed, Dec 21, 2016 at 10:10 PM, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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'.

On Mon, Jan 9, 2017 at 11:54 PM, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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?

On Tue, Jan 17, 2017 at 7:11 PM, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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(a)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.

On Fri, Jan 20, 2017 at 4:04 PM, Stephen Smalley <sds(a)tycho.nsa.gov&gt; 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.

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). > > > 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. 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.