Description of problem: selinux is preventing kismet to start Version-Release number of selected component (if applicable): rpm -qa selinux* selinux-policy-3.6.12-53.fc11.noarch selinux-policy-targeted-3.6.12-53.fc11.noarch rpm -qa kismet kismet-0.0.2008.05.R1-5.fc11.i586 How reproducible: always Steps to Reproduce: 1. install kismet 2. configure kismet to use the right hardware (kismet.conf source=..) 3. start kismet Actual results: kismet is failing to start. to get all AVCs I started kismet in permissive mode: semanage permissive -a kismet_t the relevant part of the audit.log is attached Expected results: kismet starting Additional info: the original post on fedora-selinux-list: https://www.redhat.com/archives/fedora-selinux-list/2009-July/msg00035.html
Created attachment 350549 [details] content of audit.log after starting kismet in permissive mode
Miroslav, you need to add kernel_read_system_state(kismet_t) Add a kismet_tmpfs_t and allow kismet_t to manage_files_pattern on it. Also need to add dbus_system_bus_client(kismet_t) networkmanager_dbus_chat(kismet_t)
Fixed in selinux-policy-3.6.12-64.fc11
I upgraded to 3.6.12-65. rpm -qa selinux* selinux-policy-3.6.12-65.fc11.noarch selinux-policy-targeted-3.6.12-65.fc11.noarch kismet starts up fine now but generates some other AVCs regarding sound. I will attach audit.log (kimet_t in permissive mode).
Created attachment 351357 [details] AVCs using selinux-policy-3.6.12-65
Why is kismet reading a file in the /root directory? /root/group_map? Why is it using pulseaudio at all?
> Why is kismet reading a file in the /root directory? /root/group_map? This was caused by the default kismet configuration which sets the configdir to the home directory of the user: kismet.conf - line 373: configdir=%h I changed it to /var/lib/kismet/ as you sugguested some time ago [1] - this worked out. I will file a bugreport against the kismet package to change this default setting, as this seams to be the bether solution than allowing kismet to read files in $HOME. [1] https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=threaded&order=DESC&topic_id=63791&forum=10&move=prev&topic_time=1226501702 Regarding pulseaudio: Kismet usually plays a sound if a new network was found. Sound can be turned of in kismet_ui.conf line 25: 25 #sound=true (altough the policy should allow this for people using the sound feature) Deactivating sound and changing the configdir to /var/lib/kismet/ resolved the issues previously mentioned. thanks! Christoph A.
Chris would it play sound for you if kismet was running as root?
No, because play is also trying to access files in $HOME (/root/.pulse-cookie). I will attach remaining avcs when sound is turned on in kismet_ui.conf.
Created attachment 353853 [details] kimet-play-avcs (kismet_t in permissive mode)
What I am asking is, could you hear sounds if SELinux was in permissive mode or disabled if you were running kismet as root.
In neither case. So I guess it is not an SELinux issue at all..
So really you do not want kismet trying to play around in your /root directory at all, So I would disable sound when running kismet as root.
Yes for me it is OK running kismet without sound, altough I'm wondering why sound with kismet is not working even if SELinux is in permissive mode. I will try to track that down... thanks! Christoph
I don't believe pulseaudio running as root will communicate with pulseaudio running as non root, So you can't have processes running as root effecting sounds in the user space. (Realize that I know very little about this.) But we had similar problems with svirt and turned off pulseaudio since it was not doing anything useful.
In fact kismet is dropping root privileges and running as user 'kismet' because of the suiduser=kismet configuration. Looking at the process table its like that: ps auxZ|grep kismet unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2749 0.0 0.0 110628 3396 pts/0 Sl 20:39 0:00 /usr/bin/play /usr/share/kismet/wav/new_network.wav unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2753 0.0 0.0 20064 2240 pts/0 S 20:39 0:00 /usr/bin/pulseaudio --start --log-target=syslog unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 root 2873 0.0 0.0 3164 556 pts/0 S+ 20:40 0:00 kismet unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2874 0.2 0.0 4576 1888 pts/0 S+ 20:40 0:00 /usr/bin/kismet_server --silent unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 root 2875 0.1 0.0 4292 308 pts/0 S+ 20:40 0:00 /usr/bin/kismet_server --silent unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2876 0.0 0.0 4292 368 pts/0 S+ 20:40 0:00 /usr/bin/kismet_server --silent unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2877 0.0 0.0 109604 3392 pts/0 Sl+ 20:40 0:00 /usr/bin/play /usr/share/kismet/wav/new_network.wav unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 kismet 2883 0.0 0.0 20064 2032 pts/0 S+ 20:40 0:00 /usr/bin/pulseaudio --start --log-target=syslog unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 root 2886 0.2 0.0 4364 1748 pts/0 S+ 20:40 0:00 /usr/bin/kismet_client unconfined_u:unconfined_r:kismet_t:s0-s0:c0.c1023 root 2887 0.0 0.0 4044 332 pts/0 S+ 20:40 0:00 /usr/bin/kismet_client which looks quite strange to me because I see 3 instances of kismet_server insteat of 1. But anyway beside sound - something I personally don't need in kismet - it works. thanks Christoph
fwiw, recent upstream version (which is in rawhide now) changed way how processes are started. Now, 'kismet' is started by normal user and will be asked through a consolehelper to start a wrapper which talks to the hardware. I removed all the 'kismet' user stuff (logdir, homedir, user-creation) there. I think, recent SELinux policy won't work with the new package anymore.
Why is it using consolehelper instead of dbus/policykit? I though consolehelper was on the way out.
consolehelper was introduced by me (and I do not have any clue how I could replace it with dbus or policykit). Upstream uses a setuid binary and requires that users are members of special group. But I think that consolehelper is the better solution.
Basic separation between the client and server componant of kismet. kismet_server required root privs, client should not, and output communication by dbus.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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