Re: kismet 2011.03.R2-1: Please review debconf PO/control for the package kismet
2012/11/7 Justin B Rye <jbr@edlug.org.uk>:
> Nick Andrik wrote:
>> Justin B Rye <jbr@edlug.org.uk>:
>>> 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)
>
> Reading it again, yes, we should probably have some mention of that,
> but I'd prefer not to add it at the end - maybe:
>
> Kismet needs root privileges for some of its functions. However, running it
> as root ("sudo kismet") is not recommended, since running all of the code
> with elevated privileges increases the risk of bugs doing system-wide
> damage. Instead Kismet can be installed 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.
>
> [...]
>> 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
>
> Fair enough, we've got room. (I don't like the colon, though.)
OK, I like it better this way now
>>>> .
>>>> 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.
>
> Do you mean "(Desktop) PCs" or "computers that are personal"? Saying
> "personal computers" makes it sound as if you *don't* mean to
> include laptops (or palmtops and so on), but form factor isn't the
> issue here; the question is just whether it's a single-user system.
I mean personal (not multiuser) computers.
BTW, I thought computers included laptops, but OK.
> But what's unsafe about making it setuid on a multi-user system,
> anyway? Even if I don't trust my little brother, the argument
> against "sudo kismet" is still valid, which implies that kismet
> should still be installed with the setuid bit set - we should just
> be warning against letting untrusted users in the kismet group!
Agreed, I also cannot see why setuid with group permissions can be any
insecure at all (or at least more insecure than ssudo), so maybe we
could get the warning out?
> So I would suggest:
>
> .
> Enabling this feature allows users in the "kismet" group to run Kismet
> (and capture packets, change wireless card state, etc), so only thoroughly
> trusted users should be granted membership of the group.
> .
> For more detailed information, see section 4 of the Kismet README
> ("Suidroot & Security"), which can be found at
> /usr/share/doc/kismet/README or "http://www.kismetwireless.net/README";.
>
>>>> 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'm always cautious around the word "monitor", since of course it's
> also a piece of hardware. But maybe that does work. Okay, why not.
> (Oops, and I had left kismet-plugins with a capitalised synopsis;
> fixed now.)
We can keep the sniffer like this and change the monitor to monitoring?
I don't have a problem for any case, I just what to convey the message
>>> * 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.
>
> Wifi hardware manufacturers certainly use codes like 802.11abg to
> label multi-mode devices, but in principle a new amended standard
> might come out with a name like 802.11ag, so I would feel safer
> using "802.11a/b/g/n".
Actually there is no such case, check from wikipedia:
http://en.wikipedia.org/wiki/802.11#In_process
To reduce confusion, no standard or task group was named 802.11l,
802.11o, 802.11q, 802.11x, 802.11ab, or 802.11ag.
But I like a/b/g/n anyway
>>> * I'm not convinced "speak out" works as a transitive verb like
>>> this, though it's hard to find an alternative;
>
> I've worked out what the alternative was: "read out" (or "read
> aloud").
>
> Revised version attached.
>
> Oh, I forgot to add my traditional Why The Name footnote. README
> §18 says: "I really just [...] clicked through a thesaurus until I
> found a word that wasn't used in any other OSS projects".
I understood nothing at all here, elaborate please :D
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package
Reply to: