Re: kismet 2011.03.R2-1: Please review debconf PO/control for the package kismet
Hi Justin,
First of all, thank you very much for your really valuable help
2012/11/6 Justin B Rye <jbr@edlug.org.uk>:
> Nick Andrik wrote:
>> Could you please make a review on the newly prepared kismet package?
>
> Okay, here are some comments; I suspect I'll need some corrections
> before my revised version is ready. Starting with the templates:
>
>> Template: kismet/install-setuid
>> Type: boolean
>> Default: true
>> _Description: Should Kismet be installed to run with setuid privs?
>
> Well, for a start "privs" is jargon. I would like to be able to find
> a way of avoiding "setuid" too, but I don't think that's possible -
> this isn't a simple case of "should it run as root?"
Yes, this is the case and there are two modes to do that:
a) running as root (sudo kismet)
b) setting setuid and running as normal user (with root capabilities
for the capture program)
>> Kismet can be installed as setuid (recommended) or as standard (root required).
>
> I don't think "standard" works.
>
>> Running Kismet as setuid is recommended over running it as root, because
>> most parts of Kismet (such as the UI and the parts that decode packets) will
>> not run with elevated privileges, reducing the risk of bugs leading to
>> system-wide harm.
>
> I'd like to try to rearrange this so that it has something more like
> an explanation of what setuid is (and what problem it solves) at the
> start. My current suggestion:
>
> Kismet needs root privileges for some of its functions. To minimize
> the amount of code that runs with elevated privileges (and reduce the
> risk of bugs doing system-wide damage) it is recommended to install
> Kismet with the "setuid" bit set, which will allow it to grant these
> privileges automatically to the processes that need them, excluding
> the user interface and packet decoding parts.
>
> (This leaves unstated the alternative of getting root "manually".)
Do you think we should specify that? Then we should say something like:
If you decide not to use setuid, then you will have to run kismet as
root (e.g. sudo kismet)
>> For more detailed information, please see the "Suidroot & Security" section
>> of the Kismet README at:
>> http://www.kismetwireless.net/README
>> or
>> /usr/share/doc/kismet/README
>
> We don't need to point at two different copies - that's the default
> location for a Kismet README under Debian anyway. (And why not
> mention that it's section 4?)
I would not leave the path out, since I don't expect the users to know
by heart where to find the documentation.
Moreover, the advantage of having the url there is that the people can
directly click (even in terminal there is "open to browser") and have
the information immediately available
I would propose something like this:
For more detailed information, see section 4 of the Kismet README
("Suidroot & Security"), which can be found at:
http://www.kismetwireless.net/README or
/usr/share/doc/kismet/README
>> .
>> Enabling this feature allows users in the 'kismet' group to run Kismet (and
>> capture packets, change wireless card state, etc). Do NOT enable setuid
>> Kismet if you have untrusted users on your system.
>> .
>> Most users running Kismet on personal laptops should install it as setuid.
>
> This is all okay - I've just edited it to match the standard
> debian-l10n-english "stylesheet", with double quotes and single-spaced
> sentences.
Now that I see it, I guess we should replace "laptops" with "computers", no?
Most users running Kismet on personal computers should install it as setuid.
>> Template: kismet/install-users
>> Type: string
>> _Description: Users to add to the kismet group
>> Only users in the kismet group are able to use kismet under the setuid model.
>> .
>> List users, separated by spaces, to be added to the group.
>
> It's easy to misinterpret "list users" as a noun phrase, and then be
> further confused at the mental image of people separated by spaces...
> make it:
>
> Please specify the users to be added to the group, as a
> space-separated list.
>
>> .
>> NOTE: After adding users to a group, typically they must log out and log in
>> again before the group is recognized.
>
> I'm never keen on "PAY ATTENTION TO THIS BIT" signs, and I'd rephrase
> the sentence to avoid subject-reference confusion:
>
> Note that currently logged-in users who are added to a group will
> typically need to log out and log in again before it is recognized.
>
> (In fact you can "re-log-in on the spot" by saying "su - $USER", but
> CLI-phobics don't need to hear about that.)
I think this works only for the new terminal and not the whole GUI, no?
Probably those interested in doing this, already know how to do so.
> Meanwhile in the control file:
>
>> Package: kismet
>> Architecture: any
>> Depends: ${shlibs:Depends}, ${misc:Depends}, adduser, libcap2-bin
>> Suggests: kismet-plugins, festival, gpsd
>> Description: Wireless sniffing and monitoring - core
>> Kismet is an 802.11 layer2 wireless network detector, sniffer, and
>> intrusion detection system. It will work with any wireless card
>> that supports raw monitoring (rfmon) mode and can sniff 802.11b,
>> 802.11a, and 802.11g traffic.
>
> Ah, slightly improved phrasing from the Squeeze version. But
> * no need to capitalise "Wireless";
> * in principle the old "...monitoring tool" synopsis had better
> DevRef compliance (as a noun phrase describing the package), but
> this works well enough;
That is "wireless sniffer and monitor". Do you think it'd be better?
> * I'd say "layer-2" (possibly even "layer two");
> * we're standardising on single-spaced sentences;
> * it needs a comma after "mode" to make it clear that "can sniff" is
> syntactically parallel to "work", not "supports" (it isn't saying
> "any card that supports foo and can sniff bar and baz");
> * you've updated the old blurb that only said it could do 802.11b,
> but the README says it can do 802.11n, too! (Also, why list
> 802.11b before 802.11a?)
>
> So I've got:
>
> Description: wireless sniffing and monitoring - core
> Kismet is an 802.11 layer-2 wireless network detector, sniffer, and
> intrusion detection system. It will work with any wireless card that
> supports raw monitoring (rfmon) mode, and can sniff 802.11a, 802.11b,
> 802.11g, and 802.11n traffic.
Isn't there a way to group the protocols like 802.11abgn or it seems
too technical?
I saw this kind of presentation for supported protocols of wireless cards.
>> .
>> It can use festival to play audio alarms for network events,
>> can speak out network summary on discovery, and optionally works with
>> gpsd to map scanning.
>
> Er, now I'm confused. The Squeeze version used to suggest sox, and
> said it could use (a) sox and (b) festival to (a) play alarms and (b)
> speak, but now it seems to be saying I need to install festival just
> to make it go beep. Is that true? Also:
> * I'm not convinced "speak out" works as a transitive verb like
> this, though it's hard to find an alternative;
> * "optionally works" is redundant (unless it's got a configuration
> option "BROKEN=NO");
> * what does "to map scanning" mean?
> Retreating into vagueness, my suggestion is:
>
> It can use other programs to play audio alarms for network events,
> announce network summaries as speech, or provide GPS coordinates.
I will check the actual programs and put them as suggestions
>> .
>> This is the main package containing the core, client and server.
> ^
> Insert serial comma for consistency.
>
>>
>> Package: kismet-plugins
>> Architecture: any
>> Depends: ${shlibs:Depends}, ${misc:Depends}, kismet(= ${binary:Version})
>> Enhances: kismet
>> Description: Wireless sniffing and monitoring - plugins
>> Kismet is an 802.11 layer2 wireless network detector, sniffer, and
>> intrusion detection system. It will work with any wireless card
>> that supports raw monitoring (rfmon) mode and can sniff 802.11b,
>> 802.11a, and 802.11g traffic.
>> .
>> It can use festival to play audio alarms for network events,
>> can speak out network summary on discovery, and optionally works with
>> gpsd to map scanning.
>
> All as above. Hang on, though - shouldn't it suggest spectools?
Probably yes, I will add it.
>> This package contains the following extra plugins for kismet:
>> autowep: Easily detect the WEP key from BSSID and SSID
>> btscan: Basic scan support for Bluetooth, aka 802.15.1
>> dot15d4: Support for 802.15.4 protocol
>> ptw: Performs the Aircrack-NG PTW attack against data captured by Kismet
>> spectools: Links to the Spectools spectrum analyzer network export
>
> These linebreaks will be reflowed in most displays; you need to make
> it a proper indented list, with bullet points. I'll also rephrase
> them slightly:
>
> This package provides the following extra plugins for Kismet:
> * autowep: detects the WEP key from BSSID and SSID;
> * btscan: basic scan support for the 802.15.1 (Bluetooth) protocol;
> * dot15d4: support for the 802.15.4 Personal Area Network protocol;
> * ptw: performs the Aircrack-NG PTW attack against captured data;
> * spectools: imports data from the spectools spectrum analyzer.
I totally agree with all other suggestions
Many thanks again!
Nick
--
=Do-
N.AND
Reply to: