[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[guido@trentalancia.com (Guido Trentalancia)]

On Tue, 2011-03-22 at 09:42 -0400, Eric Paris wrote:
> On Tue, 2011-03-22 at 08:11 -0400, Daniel J Walsh wrote:
> > On 03/20/2011 06:41 PM, Guido Trentalancia wrote:
> > > On Mon, 2011-03-21 at 08:55 +1100, Russell Coker wrote:
> > >> On Mon, 21 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > >>>> Sounds like we want to allow the wpa_suplicant to do this.
> > >>>
> > >>> Not everybody likes that to happen. And surely there must be a good
> > >>> reason for having a "neverallow" rule in kernel/kernel.te which blocks
> > >>> everything.
> > >>>
> > >>> See Bug#515136 on Debian but even more importantly Bug#684415 on Fedora.
> > >>
> > >> That Debian bug isn't relevant.
> > > 
> > > It's old, I think or it lacks details. But it was just to show that it
> > > is (or it was) happening on Debian. I think I told you already that the
> > > Fedora bug is more relevant.
> > > 
> > >> Dan asked "Why would wpa_supplicant be loading kernel modules directly?".  You 
> > >> have answered that question in this discussion, you could include your answer 
> > >> in the Red Hat Bugzilla if you want.
> > >>
> > >> On Mon, 21 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> > >>> So unless Dan Walsh changes his mind there needs to be at least one
> > >>> ifdef (for DISTRO=redhat).
> > >>
> > >> If Dan has expressed an opinion on this matter then please cite a reference.  
> > >> Asking why something happens is a long way from stating an opinion that it 
> > >> shouldn't be permitted.
> > > 
> > > The reference was the Fedora bug.
> > > 
> > > I think it's rather obvious that wpa_supplicant might need to load
> > > modules for crypto or wireless cards. So in my opinion Dan's question
> > > should not be interpreted literally. But all of this is pointless now as
> > > eventually people will get back on this tomorrow.
> > > 
> > >>> I am happy to prepare a patch which does can_load_kernmodule()/dontaudit
> > >>> depending on the distribution, but I need to hear from people with
> > >>> authority for each distribution. And Christopher should decide what
> > >>> would be the default behaviour.
> > >>
> > >> You have already heard from me.
> > > 
> > > Yes, I agree with you that it is safe to use sys_module but I would like
> > > to hear from others. So the patch was intended to remind us of that
> > > issue mainly, as even if it was applied by mistake or without
> > > discussion, it won't change the current situation. The description of
> > > the patch makes it clear that normal functioning of wpa_supplicant might
> > > be affected and that is the important thing.
> > > 
> > >> Don't get too bothered about getting support from different distributions, no-
> > >> one else worries much about such things.
> > > 
> > > Well, on my system the relative modules are loaded before wpa_supplicant
> > > is started. There might be systems where wpa_supplicant would not be
> > > able to load modules and the network would not work. I don't think this
> > > is desirable.
> > > 
> > > Regards,
> > > 
> > > Guido
> > > 
> > > _______________________________________________
> > > refpolicy mailing list
> > > refpolicy at oss.tresys.com
> > > http://oss.tresys.com/mailman/listinfo/refpolicy
> > 
> > 
> > Eric is investigating right now whether this is a kernel bug.  If I
> > understand correctly the kernel is allowing wpa supplicant to load a
> > some kernel modules as long as they are named properly.  I had better
> > let Eric explain the rest.
> 
> I'm hoping to blame
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8909c9ad8ff03611c9c96c9a92656213e4bb495b
> Which causes any time a program trying to get the kernel to auto-load a
> module named netdev-* the process needs CAP_NET_ADMIN but if they try to
> get it to load a module that doesn't start with "netdev" the process
> needs CAP_SYS_MODULE.  Now that patch should have created some dmesg
> output if the process was granted CAP_SYS_MODULE (as should be the case
> when permissive) but in both cases I've seen data from users I don't see
> the dmesg output (and the module fails to load)  I'm looking into it....

In the specific case of the test machine I was using the modules were
getting loaded as soon as the PCMCIA card was plugged in, so they were
already loaded before wpa_supplicant. This does not necessarily reflect
other possible cases.

However, if I force rmmod before starting wpa_supplicant and sys_module
is enabled, then I get this to stdout (vanilla 2.6.38):

Loading kernel module for a network device with CAP_SYS_MODULE
(deprecated).  Use CAP_NET_ADMIN and alias netdev-wlan1 instead

On the other hand if I force rmmod before starting wpa_supplicant and
sys_module is not enabled by policy, then the modules cannot be loaded
and wpa_supplicant dies (the latter is also documented in the man page
and in any case it's obvious as it can't proceed).

Hope it helps.

Regards,

Guido