: dontaudit sys_module wpa_supplicant

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?

Quoted 1 line

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.

Quoted 5 lines · On Sunday 20 March 2011 12:24:03 Guido Trentalancia wrote:

Quoted 1 line

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.

Quoted 3 lines · Guido Trentalancia

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

Quoted 4 lines

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.

Quoted 7 lines · Guido Trentalancia

Quoted 4 lines

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.

Quoted 27 lines · Sven Vermeulen

Quoted 7 lines · Guido Trentalancia

Quoted 4 lines

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)

Quoted 6 lines

')

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

Quoted 1 line

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.

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.

Quoted 7 lines · Guido Trentalancia

Quoted 1 line

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.

Quoted 2 lines · Guido Trentalancia

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.

Quoted 4 lines

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.

Quoted 10 lines · Russell Coker

Quoted 7 lines · Guido Trentalancia

Quoted 1 line

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.

Quoted 11 lines

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.

Quoted 2 lines · Guido Trentalancia

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 57 lines · Guido Trentalancia

Quoted 10 lines · Russell Coker

Quoted 7 lines · Guido Trentalancia

Quoted 1 line

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.

Quoted 11 lines

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.

Quoted 2 lines · Guido Trentalancia

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 8 lines

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.

Quoted 68 lines · Daniel J Walsh

Quoted 57 lines · Guido Trentalancia

Quoted 10 lines · Russell Coker

Quoted 7 lines · Guido Trentalancia

Quoted 1 line

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.

Quoted 11 lines

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.

Quoted 2 lines · Guido Trentalancia

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 8 lines

Regards,

Guido

_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

Quoted 4 lines

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

Quoted 57 lines · Guido Trentalancia

Quoted 10 lines · Russell Coker

Quoted 7 lines · Guido Trentalancia

Quoted 1 line

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.

Quoted 11 lines

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.

Quoted 2 lines · Guido Trentalancia

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.

Quoted 6 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 8 lines

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.

From a refpolicy point of view if sys_module should not be allowed, then