Greg Morris wrote:
> Response to questions by ULFL...
>
> > But which privileges are affected and in which way?
>
> (t)ethereal is typically run as root only in order be able to sniff
> network
> interfaces. A process running as root however has quite a few capabilities
> beyond an ordinary user process. Those extra capabilities (for
> example, the
> capability to insert modules into the running kernel or to write to
> arbitrary files regardless of their permission bits) are not needed at all
> for (t)ethereal's operation but can be abused by an exploit for a security
> vulnerability in ethereal (or its protocol decoders).
Wouldn't it be a good idea to do it the other way round? Usually running
Ethereal in user level and raise capabilities (somehow like su does it),
when needed while capturing.
Please note, that I've done some cleanup to the capturing code, so it
will always use the two task mode for capturing so this should be possible.
However, lowering the privileges when running as root might be a good
idea anyway...
>
> What the patch does is to use a small userspace library (libcap) to
> drop all
> the root capabilities (t)ethereal doesn't need as fast as possible,
> keeping
> just the CAP_NET_RAW capability needed to sniff network interfaces. This
> mitigates the harm exploits can cause.
>
> For background on the capabilities model in Linux, see
> http://www.tldp.org/HOWTO/Secure-Programs-HOWTO/processes.html
> and
>
> http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt
I've added both links to
http://wiki.ethereal.com/Development_2fPrivilegeSeparation
> Correct; this patch is a no-op on systems without libcap. It uses a
> configure fragment to detect whether libcap (and thus the cap_
> functions) is
> available. By default, libcap will be used when it is available; through
> --with-cap=no libcap use can be disabled even when libcap is available on
> the system.
Huh, I've mixed HAVE_LIBCAP and HAVE_LIBPCAP, so I was confused and
thought that might make trouble on win32. But as these are different
settings, there shouldn't be a problem here.
Someone with more Linux knowledge than me may have a look at the patch.
I won't check in things I don't understand (and cannot test).
Regards, ULFL
