Hi Marc,

2011/11/22 Marc Haber <[email protected]>:
> On Tue, Nov 22, 2011 at 03:12:06PM +0100, Bálint Réczey wrote:
>> Have you seen any suspicious output while running 'sudo
>> dpkg-reconfigure wireshark-common' ?
>>
>> Could you please check the output of the following commands?:
>>
>> sudo dpkg-reconfigure wireshark-common
>> /usr/sbin/dpkg-statoverride --list /usr/bin/dumpcap
>> echo $?
>> sudo which setcap
>
> I now know what went wrong. I was misguided by the name of the debconf
> template being install-setuid, which prompted me to an immediate "no",
> without knowing that the postinst will only use setuid as a
> last-resort method if capabilities are not available.
The template name is not shown to users AFAIK and
the current template text does not mention setuid bit:

Should non-superusers be able to capture packets?
 Dumpcap can be installed in a way that allows members of the "wireshark"
 system group to capture packets. This is recommended over the
 alternative of running Wireshark/Tshark directly as root, because
 less of the code will run with elevated privileges.
 .
 For more detailed information please see
 /usr/share/doc/wireshark-common/README.Debian.
 .
 Enabling this feature may be a security risk, so it is disabled by
 default. If in doubt, it is suggested to leave it disabled.


> Additionally, the distance between the db_get call and the usage of
> the RET variable in the postinst led me into a wrong way.
I agree that db_get and RET could be closer, but I consider the
current code readable enough to keep it.

> I would like to suggest clarifying the wording of the debconf template
> or at least the README.Debian. Additionally, the possible security
> risk of using capabilities mentioned in the Debconf template should be
> explained in the README.Debian to avoid knee-jerk "no" answers by
> paranoid users like me.
Related part of current README.Debian:

I. Capturing packets with Wireshark/Tshark

   There are two ways of installing Wireshark/Tshark on Debian:

   I./a. Installing dumpcap without allowing non-root users to capture packets

      Only root user will be able to capture packets. It is advised to capture
      packets with the bundled dumpcap program as root and then run
      Wireshark/Tshark as an ordinary user to analyze the captured logs. [2]

      This is the default on Debian systems.

   I./b. Installing dumpcap and allowing non-root users to capture packets

      Members of the wireshark group will be able to capture packets on network
      interfaces. This is the preferred way of installation if Wireshark/Tshark
      will be used for capturing and displaying packets at the same time, since
      that way only the dumpcap process has to be run with elevated privileges
      thanks to the privilege separation[1].

      Note that no user will be added to group wireshark automatically, the
      system administrator has to add them manually.

      The additional privileges are provided using the Linux Capabilities
      system where possible or using the set-user-id bit, where the Linux
      Capabilities are not present (Debian GNU/kFreeBSD, Debian GNU/Hurd).

      Linux kernels provided by Debian support Linux Capabilities, but custom
      built kernels may lack this support. If the support for Linux
      Capabilities is not present at the time of installing wireshark-common
      package, the installer will fall back to set the set-user-id bit to
      allow non-root users to capture packets.

      If installation succeeds with using Linux Capabilities, non-root users
      will not be able to capture packets while running kernels not supporting
      Linux Capabilities.


   The installation method can be changed any time by running:
   dpkg-reconfigure wireshark-common


I think it is clear that setting the setuid bit is a fall-back.

> I guess that there are many users who would happily grant dumpcap the
> required capabilities but would not agree to have it suid root. Hiding
> both methods behind the same debconf question may be confusing.
Being able to capture on localhost may be considered a serious
security problem, for those happy ones, too. :-)

> Text suggestion:
> The package scripts will use Linux capabilities for the dumpcap binary
> where available and resort to setting the suid bit on the dumpcap
> binary as a fall-back.
The technology used behind the scenes is hidden intentionally to prevent
changes to the template. The template is localized thus changing it would
mean a lot of work for translators.
It refers to README.Debian, because the full story needs more
explanation than what would fit in a template text.

If you feel that  README.Debian could be clarified even more, please
send a patch against it, but please don't change the template.
I'm thinking about adding details about capturing USB frames, thus this
would be the right time for changing README.Debian at other places, too.

Cheers,
Balint



--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to