Description of problem: Kismet fails to launch due to SELinux Policy. Version-Release number of selected component (if applicable): 0.0.2008.05.R1-2.fc9 How reproducible: Everytime. Steps to Reproduce: 1. Install kismet. 2. Edit /etc/kismet/kismet.conf and change suiduser and source. 3. An AVC message will appear (the sheriff starred setroubleshoot). Actual results: Kismet fails to launch. Expected results: Kismet launches. Additional info: setroubleshoot suggested I post this bug report.
Beech, Could you send here the AVC denial as attachment?
Created attachment 314440 [details] Kismet AVC Report 1
Created attachment 314442 [details] Kismet AVC Report 2
*** Bug 448105 has been marked as a duplicate of this bug. ***
Older bug is a duplicate of a newer? Never mind if somebody fixes it...
Fixed in selinux-policy-3.3.1-87.fc9
Ok, here I seem to continue to have a problem between Kismet and SELinux. Packages version : kismet-0.0.2008.05.R1-2.fc9.i386 selinux-policy-3.3.1-91.fc9.noarch If I set SELinux in permissive mode, everything work fine.
Created attachment 317684 [details] SELinux error report 1
Created attachment 317685 [details] SELinux error report 2
Fixed in selinux-policy-3.3.1-95.fc9
Ok, I have tested with the new package and I now have another error. Packages version : selinux-policy-3.3.1-95.fc9.noarch kismet-0.0.2008.05.R1-2.fc9.i386
Created attachment 319440 [details] SELinux error report 3
Fixed in selinux-policy-3.3.1-99.fc9
Ok, it don't seems to be fixed. I will attach the command line output error and the SELinux error. Packages version : selinux-policy-targeted-3.3.1-99.fc9.noarch kismet-0.0.2008.05.R1-2.fc9.i386 Thank you.
Created attachment 320588 [details] SELinux alert error
Created attachment 320589 [details] Command line output
Well I check selinux-policy-3.3.1-101.fc9.noarch And it is there.
The same error is here with packages : kismet-0.0.2008.05.R1-2.fc9.i386 selinux-policy-targeted-3.3.1-103.fc9.noarch Is there anything more that I can provide or do? I will attach the new report fro SELinux.
Created attachment 322133 [details] SELinux report error
# audit2allow -M mypol -l -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.3.1-106.fc9.noarch
Kismet fail to launch on a default F10 install with updates and SELinux enabled. I will attach the avc error.
Created attachment 325319 [details] kismet_selinux_error_f10
You can add these rules for now using # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Fixed in selinux-policy-3.5.13-28.fc10
It's me again ;) I have updated to selinux-policy-targeted-3.5.13-30.fc10.noarch and I have another problem with SELinux. I will attach the SELinux debug log and the AVC alert. Thank you.
Created attachment 326731 [details] Log output from Kismet
Created attachment 326732 [details] AVC message from Kismet
You can allow this for now. # audit2allow -M mypol -l -i /var/log/audit/audit.log # semodule -i mypol.pp Fixed in selinux-policy-3.5.13-35.fc10
There is an error with SELinux permission on xterm and kismet, here is the debug log from kismet and I will attach the AVC messages : ... Looking for startup info from localhost:2501..... found. Connected to Kismet server 2008.05.R1 on localhost:2501 Reading AP manufacturer data and defaults from /etc/kismet/ap_manuf Reading client manufacturer data and defaults from /etc/kismet/client_manuf Error opening terminal: xterm. Didn't see any weak encryption packets, unlinking weak file Sending termination request to channel control child 5264... ... RPM packages version : selinux-policy-targeted-3.5.13-38.fc10.noarch kismet-0.0.2008.05.R1-3.fc10.i386 Thank you
Created attachment 328549 [details] AVC messages from Kismet
How is your kismet_client labeled? ls -lZ /usr/bin/kismet_client? Does kidmet execute the kismet_client?
My kismet_client is labeled : jeff@portable ~ $ ls -lZ /usr/bin/kismet_client -rwxr-xr-x root root system_u:object_r:bin_t:s0 /usr/bin/kismet_client And after a restorecon on the file, it stay at that label. I think that kismet execute the kismet_client because in the log, it says it connect to the server on port localhost:2501. If you need more informations, I will be glad to provide it.
Ok that explains it, I see no reason why this should not be allowed. Miroslav could you add files_read_usr_files(kismet_t) to F9 and F10 policy.
Fixed in selinux-policy-3.3.1-118.fc9.noarch
The last update now permit to run Kismet with the default SELinux policy in place with F9 and F10. But now that kismet start just fine, it throw up those SELinux AVC errors when running on F10. I have not tested this bug with F9 for now but will try to do later this week. I will attach the console debug logs and SELinux AVC errors log. Version : kismet-0.0.2008.05.R1-3.fc10.i386 selinux-policy-targeted-3.5.13-41.fc10.noarch Thank you.
Created attachment 331383 [details] SELinux AVC errors F10
Created attachment 331384 [details] Console debug F10
Looks like kismet_client is trying to play a sound when it starts?
It seems so, kismet play sound when it detect an access point. The AVC errors don't seem to affect kismet functionality for the moment, apart from the sound.
Could you put kismet_t in permissive mode and then grab all of the avc's when it plays a sound # semanage permissive -a kismet_t Get kismet_t to play a sound # semanage permissive -d kismet_t Attach /var/log/audit/audit.log.
Created attachment 331467 [details] SELinux Permissive AVC logs This is all the AVC logs for the commands you ask.
Miroslav, I have made changes for this in Rawhide policy, you need to update F9 and F10 to allow these.
Fixed in selinux-policy-3.3.1-124.fc9
I have been unable to get kismet working in f10 also ( at all! )... I currently have selinux-policy-3.5.13-46.fc10.noarch When I start kismet I get two WARNINGS: Unable to open '/etc/kismet/ap_manuf' for reading (Permission denied) and Unable to open '/etc/kismet/client_manuf' for reading (Permission denied) but kismet does continue past this point and starts the logging. It gives the correct message about Listening on port 2501 and "Allowing connections....." It continues to "Gathering packets..." and then Launching kismet_client: /usr/bin/kismet_client Launched client, pid 3508 NOTICE: configdir '/root/' does not exist, making it. FATAL: Cound not make configdir: File exists Killed Then the session hangs I did do the trick with semanage -i ****.pp as suggested above before this test after getting avc denials. There is an avc denial at the time the process hangs with SElinux preventing the kismet_server from using the potentially mislabeled files (./kismet) Is this already known and about to be fixed in new policy not yet released?
Mike please open a new bugzilla rather then responding to an old one. I believe you probably have mislabeled files in /etc/kismet restorecon -R -v /etc/kismet To see if this changes anything. It is probably not a good idea to have kismets "configdir" in the /root directory. Not sure what that is.
OK Dan but it will be a day or two as I have other tasks to be done first before investigating kismet again. I have no idea in which directory this configdir is but it is certainly not in the real /root directory. I did restorecon for /etc/kismet but nothing changed... however I note that the new policy was implemented for f9 but not f10 as per #42!
Good news! I have been using kismet for a while with the following version and everything work fine! No more AVC errors when starting, running or playing a sound. kismet-0.0.2008.05.R1-3.fc10.i386 selinux-policy-targeted-3.5.13-47.fc10.noarch A big thanks to everyone for solving this issue! I think we can close this bug now.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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