I am running an F9 system with SELinux enabled on a laptop. I recently installed kismet (yum install kismet) to check local wireless channels so I can ensure my AP does not conflict with other boxes nearby.
I made the usual mods to the config files to set up sources etc and change the suiduser but when I try to run kismet as root (in exactly the same way as previously on boxes with SElinux disabled), I get an avc denial and on the terminal I get: FATAL: Could not open SSID track file '/home/mike/ssid_map': permision denied.
The SELinux denial contains a Summary: SELinux is preventing the kismet_server from using potentially mislabeled files (./ssid_map).
It suggested using restorecon but this makes no difference. The context remains as previously: system_u:object_r:user_home_t:s0 I removed the file and tried again but kismet won't start if the file is absent.
I also tried to use chcon to set the context for this file - and this also makes no difference - at least with the contexts I tried for kismet_log_t and kismet_t is not permitted.
Can anyone suggest how I might work around this?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mike Cloaked wrote:
I am running an F9 system with SELinux enabled on a laptop. I recently installed kismet (yum install kismet) to check local wireless channels so I can ensure my AP does not conflict with other boxes nearby.
I made the usual mods to the config files to set up sources etc and change the suiduser but when I try to run kismet as root (in exactly the same way as previously on boxes with SElinux disabled), I get an avc denial and on the terminal I get: FATAL: Could not open SSID track file '/home/mike/ssid_map': permision denied.
The SELinux denial contains a Summary: SELinux is preventing the kismet_server from using potentially mislabeled files (./ssid_map).
It suggested using restorecon but this makes no difference. The context remains as previously: system_u:object_r:user_home_t:s0 I removed the file and tried again but kismet won't start if the file is absent.
I also tried to use chcon to set the context for this file - and this also makes no difference - at least with the contexts I tried for kismet_log_t and kismet_t is not permitted.
Can anyone suggest how I might work around this?
kismet is not allowed to read files in the home directory, So you either need to move the ssid_map to a directory which kismet can read or modify policy to allow kismet to read the homedir.
/var/lib/kismet is probably a better location.
Or modify local policy with
# grep kismet /var/log/audit/audit.log | audit2allow -M mykismet # semodule -i mykismet.pp
Daniel J Walsh wrote:
kismet is not allowed to read files in the home directory, So you either need to move the ssid_map to a directory which kismet can read or modify policy to allow kismet to read the homedir.
/var/lib/kismet is probably a better location.
Or modify local policy with
# grep kismet /var/log/audit/audit.log | audit2allow -M mykismet # semodule -i mykismet.pp
Thanks Dan, that is excellent - I will do one or other when I get back to the machine tonight. I presume that the location of the ssid_map file is defined in one of the config files for kismet, in which case it should be straightforward to re-define it. If not then I will modify local policy (not done that before so should be interesting for me!)
Mike Cloaked wrote:
I presume that the location of the ssid_map file is defined in one of the config files for kismet, in which case it
I just looked at the config files on another machine and realise that the ssid_map file is defined in the main config file so easy to switch to /var/lib/kismet/ as Dan suggested.