Hi Russell !
-- original message --
Subject: Re: [refpolicy] [PATCH]: dontaudit sys_module wpa_supplicant
From: Russell Coker <[email protected]>
Date: 20/03/2011 01:11
On Sun, 20 Mar 2011, Guido Trentalancia <[email protected]> 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
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.
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
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
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
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
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
On Mon, 21 Mar 2011, Guido Trentalancia <[email protected]> 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 <[email protected]> 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/
On Mon, 2011-03-21 at 08:55 +1100, Russell Coker wrote:
> On Mon, 21 Mar 2011, Guido Trentalancia <[email protected]> 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 <[email protected]> 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
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
http://www.tresys.com | 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 <[email protected]> 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 <[email protected]> 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-----
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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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