[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Problems with firmware loader and selinux



On Apr 1, 2005 8:26 AM, Stephen Smalley <sds tycho nsa gov> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]