[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

wpa_supplicant (NetworkManager_t) tries to load kernel modules. I think
this is forbidden in the first place by a neverallow rule in
kernel/kernel.te. So the following patch simply "dontaudit" sys_module
requests from wpa_supplicant (and NetworkManager).

The inability of loading kernel modules might prevent wpa_supplicant
from being fully functional (for example, it might need to use
cryptographic algorithms provided by kernel modules for certain
authentication and ciphering protocols). In any case, a warning/error
message should still get printed out in the relative log file (so that
the user can take corrective manual action).

--- refpolicy-git-17032011/policy/modules/services/networkmanager.te	2011-01-08 19:07:21.269745618 +0100
+++ refpolicy-git-17032011-wpasupplicant-sysmodule/policy/modules/services/networkmanager.te	2011-03-19 19:56:52.232376452 +0100
@@ -36,7 +36,7 @@ init_system_domain(wpa_cli_t, wpa_cli_ex
 # networkmanager will ptrace itself if gdb is installed
 # and it receives a unexpected signal (rh bug #204161)
 allow NetworkManager_t self:capability { chown fsetid kill setgid setuid sys_nice sys_ptrace dac_override net_admin net_raw net_bind_service ipc_lock };
-dontaudit NetworkManager_t self:capability { sys_tty_config sys_ptrace };
+dontaudit NetworkManager_t self:capability { sys_module sys_tty_config sys_ptrace };
 allow NetworkManager_t self:process { ptrace getcap setcap setpgid getsched setsched signal_perms };
 allow NetworkManager_t self:fifo_file rw_fifo_file_perms;
 allow NetworkManager_t self:unix_dgram_socket { sendto create_socket_perms };

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Russell Coker]

On Sun, 20 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> wpa_supplicant (NetworkManager_t) tries to load kernel modules. I think
> this is forbidden in the first place by a neverallow rule in
> kernel/kernel.te. So the following patch simply "dontaudit" sys_module
> requests from wpa_supplicant (and NetworkManager).

Which kernel modules?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

Hi Russell !

-- original message --
Subject: Re: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant
From: Russell Coker <russell@coker.com.au>
Date: 20/03/2011 01:11

On Sun, 20 Mar 2011, Guido Trentalancia <guido@trentalancia.com> wrote:
> wpa_supplicant (NetworkManager_t) tries to load kernel modules. I think
> this is forbidden in the first place by a neverallow rule in
> kernel/kernel.te. So the following patch simply "dontaudit" sys_module
> requests from wpa_supplicant (and NetworkManager).

> Which kernel modules?

Should be kernel modules which provide cryptographic algorithms needed by wpa_supplicant for certain authentication and encryption functions employed in some wireless ethernet protocols.

Regards,

Guido

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Russell Coker]

On Sunday 20 March 2011 12:24:03 Guido Trentalancia wrote:
> > Which kernel modules?
> 
> Should be kernel modules which provide cryptographic algorithms needed by
> wpa_supplicant for certain authentication and encryption functions
> employed in some wireless ethernet protocols.

Sounds like we want to allow the wpa_suplicant to do this.

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

On Sun, 2011-03-20 at 18:12 +1100, Russell Coker wrote:
> On Sunday 20 March 2011 12:24:03 Guido Trentalancia wrote:
> > > Which kernel modules?
> > 
> > Should be kernel modules which provide cryptographic algorithms needed by
> > wpa_supplicant for certain authentication and encryption functions
> > employed in some wireless ethernet protocols.
> 
> 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.

If there are specific requirements from different distributions we can
use ifdef(distro).

Regards,

Guido

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Sven Vermeulen]

On Sun, Mar 20, 2011 at 03:53:13PM +0100, Guido Trentalancia wrote:
> 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.

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.

There's a difference between "not everybody wants this" and "this is what is
needed to have the application work as it is intended to". In refpolicy, I
think we should aim at the latter. The former is more for security
administrators that want to create their own policy.

If the mass that doesn't want this is large enough, you might want to
introduce it with a tunable_policy...

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

On Sun, 2011-03-20 at 16:05 +0100, Sven Vermeulen wrote:
> On Sun, Mar 20, 2011 at 03:53:13PM +0100, Guido Trentalancia wrote:
> > 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.
> 
> 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.

> There's a difference between "not everybody wants this" and "this is what is
> needed to have the application work as it is intended to". In refpolicy, I
> think we should aim at the latter. The former is more for security
> administrators that want to create their own policy.

If you read the Fedora bug that I mentioned in a previous message, then
you'll discover that Dan Walsh was not very keen on doing that (on
Fedora). And we are not talking about system administrators.

> If the mass that doesn't want this is large enough, you might want to
> introduce it with a tunable_policy...

My patch does "dontaudit".

Regards,

Guido

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Sven Vermeulen]

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.

Wkr,
	Sven Vermeulen

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

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).

Regards,

Guido

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Russell Coker]

On Mon, 21 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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.

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 <guido@trentalancia.com> 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.
 
> 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.

Don't get too bothered about getting support from different distributions, no-
one else worries much about such things.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

On Mon, 2011-03-21 at 08:55 +1100, Russell Coker wrote:
> On Mon, 21 Mar 2011, Guido Trentalancia <guido@trentalancia.com> 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 <guido@trentalancia.com> 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] [PATCH]: dontaudit sys_module wpa_supplicant

[Christopher J. PeBenito]

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.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

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" <cpebenito@tresys.com>
> 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

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Daniel J Walsh]

-----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 <guido@trentalancia.com> 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 <guido@trentalancia.com> 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-----

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Eric Paris]

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 <guido@trentalancia.com> 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 <guido@trentalancia.com> 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....

-Eric

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

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 <guido@trentalancia.com> 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 <guido@trentalancia.com> 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

[refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant

[Guido Trentalancia]

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 <guido@trentalancia.com> 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 <guido@trentalancia.com> 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