From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zombie2.ncsc.mil (zombie2.ncsc.mil [144.51.88.133]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id mBHFBfl4008566 for ; Wed, 17 Dec 2008 10:11:41 -0500 Received: from mail-qy0-f17.google.com (jazzdrum.ncsc.mil [144.51.5.7]) by zombie2.ncsc.mil (8.12.10/8.12.10) with ESMTP id mBHF9KJL008917 for ; Wed, 17 Dec 2008 15:09:21 GMT Received: by qyk10 with SMTP id 10so3870814qyk.18 for ; Wed, 17 Dec 2008 07:11:40 -0800 (PST) Message-ID: <494916A9.10107@gmail.com> Date: Wed, 17 Dec 2008 07:11:37 -0800 From: "Justin P. Mattock" MIME-Version: 1.0 To: Stephen Smalley CC: SE-Linux , tresys Subject: Re: ath9k capability=16 won't compile into policy References: <1229518746.31499.1.camel@localhost.localdomain> In-Reply-To: <1229518746.31499.1.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: justinmattock@gmail.com (Justin P. Mattock) Date: Wed, 17 Dec 2008 07:11:37 -0800 Subject: [refpolicy] ath9k capability=16 won't compile into policy In-Reply-To: <1229518746.31499.1.camel@localhost.localdomain> References: <1229518746.31499.1.camel@localhost.localdomain> Message-ID: <494916A9.10107@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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