From: guido@trentalancia.com (Guido Trentalancia) Date: Mon, 21 Mar 2011 18:54:05 +0100 Subject: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant In-Reply-To: References: Message-ID: <1300730045.3108.43.camel@tesla.lan> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Mon, 2011-03-21 at 15:07 +0100, Guido Trentalancia wrote: > > -- original message -- > Subject: Re: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant > From: "Christopher J. PeBenito" > Date: 21/03/2011 14:24 > > On 03/20/11 12:18, Guido Trentalancia wrote: > > On Sun, 2011-03-20 at 16:56 +0100, Sven Vermeulen wrote: > >> On Sun, Mar 20, 2011 at 04:47:27PM +0100, Guido Trentalancia wrote: > >>>> The moment you set kernel_load_module(NetworkManager_t) you're all set. The > >>>> neverallow is on all domains that do not have the can_load_kernmodule > >>>> attribute set, and with kernel_load_moduel() you set it for the specified > >>>> domain. > >>> > >>> The "neverallow" rule in kernel/kernel.te prevents NetworkManager_t from > >>> having the "sys_module" capability. > >> > >> In kernel/kernel.te: > >> > >> neverallow ~{ can_load_kernmodule kern_unconfined } self:capability sys_module; > >> > >> The kernel_load_module interface: > >> > >> interface(`kernel_load_module',` > >> gen_require(` > >> attribute can_load_kernmodule; > >> ') > >> > >> allow $1 self:capability sys_module; > >> typeattribute $1 can_load_kernmodule; > >> > >> # load_module() calls stop_machine() which > >> # calls sched_setscheduler() > >> allow $1 self:capability sys_nice; > >> kernel_setsched($1) > >> ') > >> > >> When you use kernel_load_module(NetworkManager_t), then the typeattribute > >> will add "can_load_kernmodule" as an attribute to the NetworkManager_t > >> domain. The neverallow works on all but those domains having > >> can_load_kernmodule and/or kern_unconfined set as an attribute. > > > > It seems quite difficult to explain this... > > > > I do not want to break things for distributions that do not want > > wpa_supplicant to load kernel modules and in any case I would like to > > hear from Christopher. > > > > So unless Dan Walsh changes his mind there needs to be at least one > > ifdef (for DISTRO=redhat). > > > > 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. > > > > It is perfectly fine to me (and I would probably be happier) if the > > default behaviour is can_load_kernmodule() as I do not particularly like > > "dontaudit" for stuff which just logs once (but Christopher has a > > different opinion on this, so once again nothing can be changed before > > Monday). > > > I would rather not allow > > this. We don't want > > network-facing services > > loading kernel modules. > > At least wpa_supplicant is not network-facing (would need to check > for NetworkManager). It should not be dealing with sockets and connections, > so it should be *isolated* from the network and the outside world (at least > at L3 and above). > > In any case it could be "dontaudit"ed. Some more insight into this from reading some of the code. The only network that wpa_supplicant could face is 127.0.0.1 UDP (hardcoded) for the control interface (instead of Unix sockets). This is an auxiliary functionality specific to wpa_supplicant. However, although the core functionality of wpa_supplicant shouldn't go behind Layer 2 with the Access Point, there are other auxiliary functionalities and new protocols that might bind(AF_INET): for example an http server for UPnP (not sure whether it's actually used but it is linked in). So, I agree it could be risky. Consider the code is not very straightforward to analyze because I think it shares bits with hostap (the Access Point daemon) although not all of that code is actually used by wpa_supplicant. Also, I can't see much general interest for this, so I'll stop here. Regards, Guido