From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 22 Mar 2011 08:11:30 -0400 Subject: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant In-Reply-To: <1300660909.3108.14.camel@tesla.lan> 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> Message-ID: <4D8891F2.3080809@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2IkfIACgkQrlYvE4MpobMRdACdFz4xi+79b8e6quM86SefDKu3 VhUAoNl42h24qDracrFW7LxH3Q+RNdHu =maZx -----END PGP SIGNATURE-----