From: guido@trentalancia.com (Guido Trentalancia) Date: Tue, 22 Mar 2011 16:01:35 +0100 Subject: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant In-Reply-To: <4D8891F2.3080809@redhat.com> 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> Message-ID: <1300806095.12249.15.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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. It's something public, in the sense it is widely documented in wpa_supplicant (man page and devel docs). For example, if wpa_supplicant is started and the wireless card module is not loaded, then wpa_supplicant would probably require it. It's a network configuration program, so it seems quite normal that it needs to load the network module if it is not already loaded. If that poses a security issue, it's another issue. There might be a kernel bug allowing wpa_supplicant to load the module despite sys_module is denied, but I can't check right now. >From a refpolicy point of view if sys_module should not be allowed, then it should be probably "dontaudit"ed. Consider people have already wasted a lot of time on this. I could find on Google list messages dated back in 2008 between Justin and Stephen about this. And then, all the bug reports from distributions... Regards, Guido