-- original message --
Subject: Re: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant
From: "Christopher J. PeBenito" <[email protected]>
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.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | 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" <[email protected]>
> 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