From: guido@trentalancia.com (Guido Trentalancia) Date: Wed, 23 Mar 2011 15:59:02 +0100 Subject: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant In-Reply-To: <1300801364.15421.2.camel@localhost.localdomain> References: <0Cz62XCZ8hNS.j4bfZvpJ@mail.posta.tim.it> <201103201812.14967.russell@coker.com.au> <1300632793.28926.5.camel@tesla.lan> <201103210855.53978.russell@coker.com.au> <1300660909.3108.14.camel@tesla.lan> <4D8891F2.3080809@redhat.com> <1300801364.15421.2.camel@localhost.localdomain> Message-ID: <1300892342.3197.9.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 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 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