tcpdump mailing list archives
Re: Possible to use libpcap without root privileges?
From: Guy Harris <guy () alum mit edu>
Date: Mon, 31 Jan 2011 18:24:37 -0800
On Jan 31, 2011, at 5:42 AM, markus74 () bredband net wrote:
Is it possible to use libpcap without root privileges?
$ man pcap ... Reading packets from a network interface may require that you have spe- cial privileges: Under SunOS 3.x or 4.x with NIT or BPF: You must have read access to /dev/nit or /dev/bpf*. Under Solaris with DLPI: You must have read/write access to the network pseudo device, e.g. /dev/le. On at least some versions of Solaris, however, this is not sufficient to allow tcpdump to capture in promiscu- ous mode; on those versions of Solaris, you must be root, or the application capturing packets must be installed setuid to root, in order to capture in promiscuous mode. Note that, on many (perhaps all) interfaces, if you don't capture in promiscuous mode, you will not see any outgoing packets, so a capture not done in promiscuous mode may not be very useful. In newer versions of Solaris, you must have been given the net_rawaccess privilege; this is both necessary and sufficient to give you access to the network pseudo-device - there is no need to change the privileges on that device. A user can be given that privilege by, for example, adding that privilege to the user's defaultpriv key with the usermod (1M) command. Under HP-UX with DLPI: You must be root or the application capturing packets must be installed setuid to root. Under IRIX with snoop: You must be root or the application capturing packets must be installed setuid to root. Under Linux: You must be root or the application capturing packets must be installed setuid to root (unless your distribution has a kernel that supports capability bits such as CAP_NET_RAW and code to allow those capability bits to be given to particular accounts and to cause those bits to be set on a user's initial processes when they log in, in which case you must have CAP_NET_RAW in order to capture and CAP_NET_ADMIN to enumerate network devices with, for example, the -D flag). Under ULTRIX and Digital UNIX/Tru64 UNIX: Any user may capture network traffic. However, no user (not even the super-user) can capture in promiscuous mode on an interface unless the super-user has enabled promiscuous-mode operation on that interface using pfconfig(8), and no user (not even the super-user) can capture unicast traffic received by or sent by the machine on an interface unless the super-user has enabled copy-all-mode operation on that interface using pfcon- fig, so useful packet capture on an interface probably requires that either promiscuous-mode or copy-all-mode operation, or both modes of operation, be enabled on that interface. Under BSD (this includes Mac OS X): You must have read access to /dev/bpf* on systems that don't have a cloning BPF device, or to /dev/bpf on systems that do. On BSDs with a devfs (this includes Mac OS X), this might involve more than just having somebody with super-user access setting the ownership or permissions on the BPF devices - it might involve configuring devfs to set the ownership or permis- sions every time the system is booted, if the system even sup- ports that; if it doesn't support that, you might have to find some other way to make that happen at boot time. Reading a saved packet file doesn't require special privileges. (The bit about Linux needs updating, as I think you can assign capability bits to *programs* as well. Open Solaris 11 might have BPF support, in which case the "Under BSD" might apply to it - and might also apply to AIX as well.)
In our case, we are testing an IP-stack in a "simulated" environment, this means the IP-stack-program has a "special" socket interface where we send and receive IP-packets from. For example:The traffic generator runs on 127.0.0.1:1234 (we will probably use scapy or netexpect as traffic generator and analyzer)And the simulated IP-stack program runs on the same machine on 127.0.0.1:4321 The IP-packets go directly between the traffic generator process and the IP-stack-process withouth using the NIC. Since the NIC is not used in this scenario libpcap shouldn't need root privileges, correct?
Unless some network interface - "network interface", in this context, is different from NIC; I will explain later - is being used, libpcap won't even be able to capture the traffic! A "network interface" is, to a first order of approximation, anything that shows up with "ifconfig -a": $ ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 {actual network information censored} fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078 {actual network information censored} en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 {actual network information censored} en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 {actual network information censored} This includes "lo0", which does not correspond to any hardware on my machine - it's the loopback interface. If you're using regular sockets in your application (i.e., you're ultimately using sockets with AF_INET/PF_INET and SOCK_STREAM or SOCK_DGRAM; you may have some special APIs *atop* the standard socket API, but that wouldn't be relevant here), but are sending traffic between 127.0.0.1:1234 and 127.0.0.1:4321, that traffic will use a network interface - lo0 or lo, depending on the OS you're using. If a network interface is being used - whether it's associated with hardware (a "NIC", although the "C" in "NIC" won't necessarily stand for "Card" - none of the hardware interfaces in question correspond to a "card" that was plugged into my machine, they're all devices on the motherboard) or not - libpcap might well need root privileges. Capturing on the loopback interface requires the same privileges as capturing on any other interface; that's the way the packet capture mechanisms on various OSes work - they don't do privilege checking at the interface level.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Current thread:
- Possible to use libpcap without root privileges? markus74 (Jan 31)
- Re: Possible to use libpcap without root privileges? Guy Harris (Jan 31)