Arch Linux

I have the same request as I remember exploits that have been created in order to take control of a host were kismet was running. Running suidroot only a small subset of kismet is their counter measure against such attacks

Also running suidroot leaves the logfiles under the ownership of the calling user.

suidinstall needs to change permissions of kismet_capture to the "kismet" group; to do this the "kismet" group must already be present and it is not possible to add a group in fakeroot. I can think of two workarounds. Similarly pacman clients can't install files owned by nonexistent users, though this can be worked around by the pre_install (or whatever) hook.

first:
A bootstrap package that create the kismet group: nothing more that a kismet-bootstrap.install and PKGBUILD.
The actual kismet package makedepends() and depends() on this kismet-bootstrap package

second:
kismet ./configure suidgroup="some-common-group". Afterwards, in post_install (or whatever) the ownership of the kismet_capture binary can be changed. I'm not sure if this will work, though: possibly the suidgroup configuration does more than set the ownership of one file.

third:
any other ideas?

actual third:
Possibly because of the lookup in /etc/passwd involved, while chown will not accept nonexistent group/user names, it does accept nonexistent IDs.
So, reserve a numerical group id for kismet
then ./configure --with-suidgroup=reserved_id
and in post_install() groupadd kismet -g reserved_id
*This works but generates a groupadd error.


The only difference between "install" and "suidinstall" is the binsuidinstall dependency which does nothing but install one file, kismet_capture. I believe that is the only way that SUIDGROUP is used. This seems pretty simple:
./configure --with-suidgroup=root
post_install() groupadd kismet; chown /usr/bin/kismet_capture root:kismet

It is probably a good idea to nonetheless decide on a system group ID for kismet, such that no other group may use that ID. Who decides this?

I picked group number "315" since it was free on my system. If this conflicts with any other packages, just post a comment here..

The PKGBUILD has been *really* cleaned out. It will also install kismet suid as well as provide the default plugin set that kismet ships.

Didn't realize chown clears the setuid bits.

hmm now kismet-2010-07-R1 is current

I've built kismet-2010-01-R1 with orbisvicis' PKGBUILD. It seems to build and work okee. One thing I'm not sure about is placing “mac80211 driver” in optdepends. It produces a warning from makepkg.

Anyway… I think that's the way to go for kismet package.

I've updated PKGBUILD for 2010-07-R1 version. Maybe it would be good to place version number in "_realver" and modify it for use in "pkgver", also to use "_realver" in source URL.

Updated to 2011-03-R2. At this rate it should become an official AUR package, "kismet-better", hehe.

I think orbisvis solution is properly and I will apply it tonight ..