Response to questions by ULFL...
> As I like to see someone "to take a heart" to start getting things done on
> this topic, I have some doubts about your approach (or maybe I just don't
> understand it). Unfortunately the comments you've added are quite few, so
> understanding was difficult as I don't know the cap_ stuff, sorry :-(
>
> Could you explain a bit what this is intended to do? AFAIK this is
> intended to lower privileges of the running task.
Correct.
> 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).
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.htmland
http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt> BTW: I'll guess this won't work on Win32 and probably other platforms not
> supporting the cap_ functions?!?
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.
--
Ray Dassen
Technical Support Engineer, EMEA Services Center
Novell Technical Services
http://support.novell.com/
