[using wpa_supplicant-0.5.10-4.fc8.x86_64 from koji]

Ran into the same problem, managed to fix it (but I have no bloody idea about
selinux, so whether this is 'correct' security-wise I have no idea) by utilizing
the following (with help from audit2allow):

checkmodule -M -m -o wpacli.mod wpacli.te
semodule_package -o wpacli.pp -m wpacli.mod 
semodule -i wpacli.pp 

contents of file wpacli.te:

module wpacli 1.0;

require {
        type NetworkManager_t;
        type unconfined_t;
        type unconfined_tmp_t;
        class sock_file write;
        class unix_dgram_socket sendto;
}

#============= NetworkManager_t ==============
allow NetworkManager_t unconfined_t:unix_dgram_socket sendto;
allow NetworkManager_t unconfined_tmp_t:sock_file write;

(you can add the semodule -i /path/to/wpacli.pp to /etc/rc.d/rc.local to make it
reload after a reboot, but I'm sure there's a better way to do all this...)

Dan, thoughts on this one?  wpa_cli just needs to talk to the wpa_supplicant
global control socket and the per-interface socket.  Unfortunately, the paths to
those sockets are specified in the wpa_supplciant config file, so if users
modify the default config they're on their own, but by default:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

Maciej  The policy modification is permanent, no reason to reload.

But the AVC above shows wpa_supplicant using tmp_t to communicate?  It also
looks like it wants to communicate with the unconfined_t user?

As far as I can tell, the /var/run/wpa_supplicant/<interface> unix sockets are
only used to initiate the connection[s], and most actual information exchange
happens through temporary socket[s] created in /tmp (something like
/tmp/wpa_ctrl_<pid>).  I would assume this second aspect explains the tmp_t, and
the fact wpa_cli probably runs as unconfined_t explains that...  [ie. there's
the wpa_cli command line (and wpa_gui as well I think) which runs as the user
talking to the wpa_supplicant daemon.

I'm afraid I have very little actual selinux know-how in order to better figure
out how this should be setup... maybe wpa_cli should not be running as unconfined_t?

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I don't have a system which is 'clean enough' to verify if this is fixed or not.  Were any changes actually made to the policies?

It looks like current policy has rules to allow this.

wpa_cli <-> wpa_supplicant communication still does not seem to work in F9 with:

# rpm -q wpa_supplicant selinux-policy
wpa_supplicant-0.6.4-2.fc9
selinux-policy-3.3.1-107.fc9

type=AVC msg=audit(1227792415.809:239): avc:  denied  { sendto } for  pid=8592 comm="wpa_supplicant" path="/tmp/wpa_ctrl_8594-1" scontext=unconfined_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket

/tmp/wpa_ctrl_<pid>-<seq-id> seems to be the socket created by wpa_cli, which runs unconfined when started from the command line.  Additionally, that id seems to increment with each failed PING from _cli to _supplicant.

I didn't have time to dig deeper, maybe running wpa_cli confined may be the easiest / cleanest solution.

Could you try selinux-policy-3.3.1-111.fc9

Same problem as in comment #9 with selinux-policy-3.3.1-111.fc9.

Miroslav, 

You need 

userdom_dgram_send(NetworkManager_t)

added to networkmanager.te

and


########################################
## <summary>
##	Send a message to unpriv users over a unix domain
##	datagram socket.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`userdom_dgram_send',`
	gen_require(`
		attribute 
	')

	allow $1 unpriv_userdomain;:unix_dgram_socket sendto;
')

Fixed in selinux-policy-3.3.1-115.fc9.noarch

selinux-policy-3.3.1-115.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/selinux-policy-3.3.1-115.fc9

selinux-policy-3.3.1-115.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-11122

Works with selinux-policy-3.3.1-115.fc9

selinux-policy-3.3.1-116.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/selinux-policy-3.3.1-116.fc9

selinux-policy-3.3.1-115.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note - this still exists in RHEL 5. I've filed bug 693149 against RHEL about this.