ath9k capability=16 won't compile into policy

ath9k capability=16 won't compile into policy

[Justin Mattock]

I'm not too sure if I should post this with SELinux,
refpolicy, or kernel.org,(or even wpasupplicant);
 so I decided to do all to the best of my knowledge.
when using the ath9k module with the latest git
kernel(or atleast a few days old); and the latest refpolicy (svn)
I'm seeing this avc denial show up:

Dec 16 12:33:32 name kernel: [   20.415785] type=1400
audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
comm="wpa_supplicant" capability=16
scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
Dec 16 12:33:32 name kernel: [   20.428494] type=1300
audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
key=(null)

the allow rule is:(with ath9k module)
allow system_dbusd_t self:capability sys_module;
which in turn will be rejected by checkpolicy
(capability 16)
when compiling the policy.

If I use the madwifi module the avc is similar but produces
allow system_dbusd_t self:capability { sys_admin }
(capability 12)
and will be accepted by checkpolicy.

As for setup I'm using NetworkManager from
intrepid as well as wpasupplicant

Any info would be appreciated so I can test this module out
and feel better knowing the module is not being denied in any
way, that might cause a false positive, or some other weirdness.


regards;
-- 
Justin P. Mattock

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

ath9k capability=16 won't compile into policy

[Justin Mattock]

I'm not too sure if I should post this with SELinux,
refpolicy, or kernel.org,(or even wpasupplicant);
 so I decided to do all to the best of my knowledge.
when using the ath9k module with the latest git
kernel(or atleast a few days old); and the latest refpolicy (svn)
I'm seeing this avc denial show up:

Dec 16 12:33:32 name kernel: [   20.415785] type=1400
audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
comm="wpa_supplicant" capability=16
scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
Dec 16 12:33:32 name kernel: [   20.428494] type=1300
audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
key=(null)

the allow rule is:(with ath9k module)
allow system_dbusd_t self:capability sys_module;
which in turn will be rejected by checkpolicy
(capability 16)
when compiling the policy.

If I use the madwifi module the avc is similar but produces
allow system_dbusd_t self:capability { sys_admin }
(capability 12)
and will be accepted by checkpolicy.

As for setup I'm using NetworkManager from
intrepid as well as wpasupplicant

Any info would be appreciated so I can test this module out
and feel better knowing the module is not being denied in any
way, that might cause a false positive, or some other weirdness.


regards;
-- 
Justin P. Mattock

[refpolicy] ath9k capability=16 won't compile into policy

[Justin Mattock]

I'm not too sure if I should post this with SELinux,
refpolicy, or kernel.org,(or even wpasupplicant);
 so I decided to do all to the best of my knowledge.
when using the ath9k module with the latest git
kernel(or atleast a few days old); and the latest refpolicy (svn)
I'm seeing this avc denial show up:

Dec 16 12:33:32 name kernel: [   20.415785] type=1400
audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
comm="wpa_supplicant" capability=16
scontext=system_u:system_r:system_dbusd_t:s0
tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
Dec 16 12:33:32 name kernel: [   20.428494] type=1300
audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
key=(null)

the allow rule is:(with ath9k module)
allow system_dbusd_t self:capability sys_module;
which in turn will be rejected by checkpolicy
(capability 16)
when compiling the policy.

If I use the madwifi module the avc is similar but produces
allow system_dbusd_t self:capability { sys_admin }
(capability 12)
and will be accepted by checkpolicy.

As for setup I'm using NetworkManager from
intrepid as well as wpasupplicant

Any info would be appreciated so I can test this module out
and feel better knowing the module is not being denied in any
way, that might cause a false positive, or some other weirdness.


regards;
-- 
Justin P. Mattock

Re: ath9k capability=16 won't compile into policy

[Stephen Smalley]

On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
> I'm not too sure if I should post this with SELinux,
> refpolicy, or kernel.org,(or even wpasupplicant);
>  so I decided to do all to the best of my knowledge.
> when using the ath9k module with the latest git
> kernel(or atleast a few days old); and the latest refpolicy (svn)
> I'm seeing this avc denial show up:
> 
> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
> comm="wpa_supplicant" capability=16
> scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
> key=(null)
> 
> the allow rule is:(with ath9k module)
> allow system_dbusd_t self:capability sys_module;
> which in turn will be rejected by checkpolicy
> (capability 16)
> when compiling the policy.
> 
> If I use the madwifi module the avc is similar but produces
> allow system_dbusd_t self:capability { sys_admin }
> (capability 12)
> and will be accepted by checkpolicy.
> 
> As for setup I'm using NetworkManager from
> intrepid as well as wpasupplicant
> 
> Any info would be appreciated so I can test this module out
> and feel better knowing the module is not being denied in any
> way, that might cause a false positive, or some other weirdness.

You didn't list the particular error message from checkpolicy, but I
would guess that it is a neverallow failure.  You should be using an
appropriate refpolicy interface to allow sys_module rather than directly
doing it.  However, in this case, the real problem is that dbusd did not
transition to a separate domain for wpa supplicant when it was launched.
You don't want dbusd itself to be able to insert modules.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] ath9k capability=16 won't compile into policy

[Stephen Smalley]

On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
> I'm not too sure if I should post this with SELinux,
> refpolicy, or kernel.org,(or even wpasupplicant);
>  so I decided to do all to the best of my knowledge.
> when using the ath9k module with the latest git
> kernel(or atleast a few days old); and the latest refpolicy (svn)
> I'm seeing this avc denial show up:
> 
> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
> comm="wpa_supplicant" capability=16
> scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
> key=(null)
> 
> the allow rule is:(with ath9k module)
> allow system_dbusd_t self:capability sys_module;
> which in turn will be rejected by checkpolicy
> (capability 16)
> when compiling the policy.
> 
> If I use the madwifi module the avc is similar but produces
> allow system_dbusd_t self:capability { sys_admin }
> (capability 12)
> and will be accepted by checkpolicy.
> 
> As for setup I'm using NetworkManager from
> intrepid as well as wpasupplicant
> 
> Any info would be appreciated so I can test this module out
> and feel better knowing the module is not being denied in any
> way, that might cause a false positive, or some other weirdness.

You didn't list the particular error message from checkpolicy, but I
would guess that it is a neverallow failure.  You should be using an
appropriate refpolicy interface to allow sys_module rather than directly
doing it.  However, in this case, the real problem is that dbusd did not
transition to a separate domain for wpa supplicant when it was launched.
You don't want dbusd itself to be able to insert modules.

-- 
Stephen Smalley
National Security Agency

Re: ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Stephen Smalley wrote:
> On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>     
>
> You didn't list the particular error message from checkpolicy, but I
> would guess that it is a neverallow failure.  You should be using an
> appropriate refpolicy interface to allow sys_module rather than directly
> doing it.  However, in this case, the real problem is that dbusd did not
> transition to a separate domain for wpa supplicant when it was launched.
> You don't want dbusd itself to be able to insert modules.
>
>   
yep,
It was a neverallow rule that caused the error.
As for the module, I take it the module is  good then.
Hmm.. I'm going to have to think about this one. i.g.
NetworkManager seems to have different ways
to startup. right now this is just the auto boot
mechanism.(/etc/network/interfaces).
I'll have to get back with this...
(I'll send you a status asap);
Thanks for the hint, on what I'm doing wrong.

regards;

Justin P. Mattock

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Stephen Smalley wrote:
> On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>     
>
> You didn't list the particular error message from checkpolicy, but I
> would guess that it is a neverallow failure.  You should be using an
> appropriate refpolicy interface to allow sys_module rather than directly
> doing it.  However, in this case, the real problem is that dbusd did not
> transition to a separate domain for wpa supplicant when it was launched.
> You don't want dbusd itself to be able to insert modules.
>
>   
yep,
It was a neverallow rule that caused the error.
As for the module, I take it the module is  good then.
Hmm.. I'm going to have to think about this one. i.g.
NetworkManager seems to have different ways
to startup. right now this is just the auto boot
mechanism.(/etc/network/interfaces).
I'll have to get back with this...
(I'll send you a status asap);
Thanks for the hint, on what I'm doing wrong.

regards;

Justin P. Mattock

Re: ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Stephen Smalley wrote:
> On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>     
>
> You didn't list the particular error message from checkpolicy, but I
> would guess that it is a neverallow failure.  You should be using an
> appropriate refpolicy interface to allow sys_module rather than directly
> doing it.  However, in this case, the real problem is that dbusd did not
> transition to a separate domain for wpa supplicant when it was launched.
> You don't want dbusd itself to be able to insert modules.
>
>   
Well, after loosing my patience with this,
I think I'm going to give up.
(but then again,I won't be able to sleep at night!!)
I think I'm dealing with something missing with
NetworkManager i.g. When using the "keyfile"
plugin
 it's as simple as creating a file with
you're network info and putting it in network-settings/"name"
then once NetworkManager start's, it reads that file
and viola up and running.(and hopefully  put's  NetworkManager in the right
transition etc..)
Unfortunately  I keep getting  a dead  reaction  when  using  this  
approach.
 NetworkManager: <info>  (wlan0): device state change: 1 -> 2 
 NetworkManager: <info>  (wlan0): bringing up device.
 NetworkManager: <info>  (wlan0): preparing device.
 NetworkManager: <info>  (wlan0): deactivating device (reason: 2). 

then:

 kernel: [   20.331143] type=1400 audit(1229715518.330:5): avc:  denied  
{ sys_module } for  pid=2457 comm="wpa_supplicant" capability=16 
scontext=system_u:system_r:system_dbusd_t:s0 
tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability


is triggered.

I think with redhat there is the
plugin ifcfg-rh which is similar to
what keyfile does.
Anyways thanks for the info on this.
I'll post anything if something comes up.

regards;

Justin P. Mattock








--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

[refpolicy] ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Stephen Smalley wrote:
> On Tue, 2008-12-16 at 14:26 -0800, Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>     
>
> You didn't list the particular error message from checkpolicy, but I
> would guess that it is a neverallow failure.  You should be using an
> appropriate refpolicy interface to allow sys_module rather than directly
> doing it.  However, in this case, the real problem is that dbusd did not
> transition to a separate domain for wpa supplicant when it was launched.
> You don't want dbusd itself to be able to insert modules.
>
>   
Well, after loosing my patience with this,
I think I'm going to give up.
(but then again,I won't be able to sleep at night!!)
I think I'm dealing with something missing with
NetworkManager i.g. When using the "keyfile"
plugin
 it's as simple as creating a file with
you're network info and putting it in network-settings/"name"
then once NetworkManager start's, it reads that file
and viola up and running.(and hopefully  put's  NetworkManager in the right
transition etc..)
Unfortunately  I keep getting  a dead  reaction  when  using  this  
approach.
 NetworkManager: <info>  (wlan0): device state change: 1 -> 2 
 NetworkManager: <info>  (wlan0): bringing up device.
 NetworkManager: <info>  (wlan0): preparing device.
 NetworkManager: <info>  (wlan0): deactivating device (reason: 2). 

then:

 kernel: [   20.331143] type=1400 audit(1229715518.330:5): avc:  denied  
{ sys_module } for  pid=2457 comm="wpa_supplicant" capability=16 
scontext=system_u:system_r:system_dbusd_t:s0 
tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability


is triggered.

I think with redhat there is the
plugin ifcfg-rh which is similar to
what keyfile does.
Anyways thanks for the info on this.
I'll post anything if something comes up.

regards;

Justin P. Mattock

Re: [refpolicy] ath9k capability=16 won't compile into policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Mattock wrote:
> I'm not too sure if I should post this with SELinux,
> refpolicy, or kernel.org,(or even wpasupplicant);
>  so I decided to do all to the best of my knowledge.
> when using the ath9k module with the latest git
> kernel(or atleast a few days old); and the latest refpolicy (svn)
> I'm seeing this avc denial show up:
> 
> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
> comm="wpa_supplicant" capability=16
> scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
> key=(null)
> 
> the allow rule is:(with ath9k module)
> allow system_dbusd_t self:capability sys_module;
> which in turn will be rejected by checkpolicy
> (capability 16)
> when compiling the policy.
> 
> If I use the madwifi module the avc is similar but produces
> allow system_dbusd_t self:capability { sys_admin }
> (capability 12)
> and will be accepted by checkpolicy.
> 
> As for setup I'm using NetworkManager from
> intrepid as well as wpasupplicant
> 
> Any info would be appreciated so I can test this module out
> and feel better knowing the module is not being denied in any
> way, that might cause a false positive, or some other weirdness.
> 
> 
> regards;
We label wpa_supplicant as NetworkManager_exec_t and have dbus
transition to this domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
/9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
=Nozo
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] ath9k capability=16 won't compile into policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Mattock wrote:
> I'm not too sure if I should post this with SELinux,
> refpolicy, or kernel.org,(or even wpasupplicant);
>  so I decided to do all to the best of my knowledge.
> when using the ath9k module with the latest git
> kernel(or atleast a few days old); and the latest refpolicy (svn)
> I'm seeing this avc denial show up:
> 
> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
> comm="wpa_supplicant" capability=16
> scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
> key=(null)
> 
> the allow rule is:(with ath9k module)
> allow system_dbusd_t self:capability sys_module;
> which in turn will be rejected by checkpolicy
> (capability 16)
> when compiling the policy.
> 
> If I use the madwifi module the avc is similar but produces
> allow system_dbusd_t self:capability { sys_admin }
> (capability 12)
> and will be accepted by checkpolicy.
> 
> As for setup I'm using NetworkManager from
> intrepid as well as wpasupplicant
> 
> Any info would be appreciated so I can test this module out
> and feel better knowing the module is not being denied in any
> way, that might cause a false positive, or some other weirdness.
> 
> 
> regards;
We label wpa_supplicant as NetworkManager_exec_t and have dbus
transition to this domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
/9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
=Nozo
-----END PGP SIGNATURE-----

[refpolicy] ath9k capability=16 won't compile into policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Justin Mattock wrote:
> I'm not too sure if I should post this with SELinux,
> refpolicy, or kernel.org,(or even wpasupplicant);
>  so I decided to do all to the best of my knowledge.
> when using the ath9k module with the latest git
> kernel(or atleast a few days old); and the latest refpolicy (svn)
> I'm seeing this avc denial show up:
> 
> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
> comm="wpa_supplicant" capability=16
> scontext=system_u:system_r:system_dbusd_t:s0
> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
> key=(null)
> 
> the allow rule is:(with ath9k module)
> allow system_dbusd_t self:capability sys_module;
> which in turn will be rejected by checkpolicy
> (capability 16)
> when compiling the policy.
> 
> If I use the madwifi module the avc is similar but produces
> allow system_dbusd_t self:capability { sys_admin }
> (capability 12)
> and will be accepted by checkpolicy.
> 
> As for setup I'm using NetworkManager from
> intrepid as well as wpasupplicant
> 
> Any info would be appreciated so I can test this module out
> and feel better knowing the module is not being denied in any
> way, that might cause a false positive, or some other weirdness.
> 
> 
> regards;
We label wpa_supplicant as NetworkManager_exec_t and have dbus
transition to this domain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
/9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
=Nozo
-----END PGP SIGNATURE-----

Re: [refpolicy] ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>
>>
>> regards;
>>     
> We label wpa_supplicant as NetworkManager_exec_t and have dbus
> transition to this domain.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
> /9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
> =Nozo
> -----END PGP SIGNATURE-----
>
>   
Cool thanks for the info.
I just have to figure out how
to get the machine to do that.
i.g. through dispatcher.d or network/interfaces.
one thing that I'm noticing is ubuntu's version of
NetworkManager only has two plugins(01ifupdown,keyfile);
I'll try loading another version and see if the other plugins
is what I'm missing to have dbusd transition
correctly.

regards;

Justin P. Mattock





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: [refpolicy] ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>
>>
>> regards;
>>     
> We label wpa_supplicant as NetworkManager_exec_t and have dbus
> transition to this domain.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
> /9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
> =Nozo
> -----END PGP SIGNATURE-----
>
>   
Cool thanks for the info.
I just have to figure out how
to get the machine to do that.
i.g. through dispatcher.d or network/interfaces.
one thing that I'm noticing is ubuntu's version of
NetworkManager only has two plugins(01ifupdown,keyfile);
I'll try loading another version and see if the other plugins
is what I'm missing to have dbusd transition
correctly.

regards;

Justin P. Mattock

[refpolicy] ath9k capability=16 won't compile into policy

[Justin P. Mattock]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Justin Mattock wrote:
>   
>> I'm not too sure if I should post this with SELinux,
>> refpolicy, or kernel.org,(or even wpasupplicant);
>>  so I decided to do all to the best of my knowledge.
>> when using the ath9k module with the latest git
>> kernel(or atleast a few days old); and the latest refpolicy (svn)
>> I'm seeing this avc denial show up:
>>
>> Dec 16 12:33:32 name kernel: [   20.415785] type=1400
>> audit(1229459612.411:3): avc:  denied  { sys_module } for  pid=2510
>> comm="wpa_supplicant" capability=16
>> scontext=system_u:system_r:system_dbusd_t:s0
>> tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
>> Dec 16 12:33:32 name kernel: [   20.428494] type=1300
>> audit(1229459612.411:3): arch=40000003 syscall=54 success=no exit=-19
>> a0=9 a1=8933 a2=bfadd94c a3=bfadd94c items=0 ppid=1 pid=2510
>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
>> fsgid=0 tty=(none) ses=4294967295 comm="wpa_supplicant"
>> exe="/sbin/wpa_supplicant" subj=system_u:system_r:system_dbusd_t:s0
>> key=(null)
>>
>> the allow rule is:(with ath9k module)
>> allow system_dbusd_t self:capability sys_module;
>> which in turn will be rejected by checkpolicy
>> (capability 16)
>> when compiling the policy.
>>
>> If I use the madwifi module the avc is similar but produces
>> allow system_dbusd_t self:capability { sys_admin }
>> (capability 12)
>> and will be accepted by checkpolicy.
>>
>> As for setup I'm using NetworkManager from
>> intrepid as well as wpasupplicant
>>
>> Any info would be appreciated so I can test this module out
>> and feel better knowing the module is not being denied in any
>> way, that might cause a false positive, or some other weirdness.
>>
>>
>> regards;
>>     
> We label wpa_supplicant as NetworkManager_exec_t and have dbus
> transition to this domain.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklKfg0ACgkQrlYvE4MpobPltQCfbcRlboJohHcUaUaASFMbj1LK
> /9AAoNPuDJuPv3B4tpikLzsjUPYCUe4I
> =Nozo
> -----END PGP SIGNATURE-----
>
>   
Cool thanks for the info.
I just have to figure out how
to get the machine to do that.
i.g. through dispatcher.d or network/interfaces.
one thing that I'm noticing is ubuntu's version of
NetworkManager only has two plugins(01ifupdown,keyfile);
I'll try loading another version and see if the other plugins
is what I'm missing to have dbusd transition
correctly.

regards;

Justin P. Mattock