On Apr 1, 2005 8:26 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Thu, 2005-03-31 at 17:39 -0500, Dmitry Torokhov wrote: > > I have a FC3 with day-before-yesterday pull from Linus and > > selinux-policy-targeted installed from rawhide. Everything seems to be > > working fine ecxept for my wireless card (prism54), which can't get > > it's firmware loaded. It looks like selinux policy prevents firmware > > loader to create "firmware" class device. I get avc denied search > > message for process /sbin/ip (which is ifconfig_t) and tcontext is > > sysfs_t. It looks like the rights are inherited from "ip" markings > > whereas I would say that firmware loader is should operate in > > completely different context. > > Module initialization runs in the context of the process that performs > the insertion. There is no other context at that point; if the module > creates kernel threads and reparents/daemonize's them, they will pick up > the kernel's context for subsequent operations. In the short term (i.e. > until FC3 policy gets updated to allow this), you can customize your > policy sources, e.g.: > yum install selinux-policy-targeted-sources > cd /etc/selinux/targeted/src/policy > audit2allow -d -l -o domains/misc/local.te > <review domains/misc/local.te and remove anything you didn't want to allow> > make load Thank you for the pointer. I still have some concerns though - I am not sure that just policy update is enough: In case of prism54 firmware is loaded not at the module initialization time but at open (configure interface) time to, as far as I understand, avoid issues when driver is built in the kernel since userspace (and therefore firmware) might not be uawailable at that time. What I am trying to say is that firmware loader can potentially be invoked as a result of "unpriveleged" access - I do not a really see why /sbin/ip should be given sysfs_t or other rights, the utility itself does not try to access sysfs. We can't even say that kernel accesses sysfs on its behalf since /sbin/ip does not care, firmware loading is kernel private mechanism. So the question is - should there be a way for the kernel to temporary switch context to "kernel" before executing some operations? I could hack firmware loader to always start a new thread, but I wonder if we have more places that need to temporarily override callers context and therefore more general solution is needed. Thank you. -- Dmitry
