Use Linux capabilities about arp-scan HOT 6 CLOSED

Yes, that should be possible. arp-scan doesn't really need to be root; it just needs whatever libpcap needs to send and receive on the Ethernet interface. That's probably just CAP_NET_ADMIN and CAP_NET_RAW.

It'll need to be able to work on all supported OSes like Linux, *BSD and Solaris (although I'm not sure if anyone still runs arp-scan on Solaris). But I believe ntp uses capabilities when available, and that runs on all the platforms that arp-scan does.

I guess it'll add a dependency on the libcap libraries (libcap-dev on Debian), which can be handled at configure time. We'll need to watch out for cross-compiling, as I know some people cross-compile from Intel to ARM, probably for Raspberry pi.

from arp-scan.

POSIX.1e capabilities support added in commit 923f123

Uses capabilities when libcap headers and library are present (configure option --with-libcap, defaults to auto). Might need to install libcap-dev or similar package to get these.

arp-scan is capabilities aware. It needs CAP_NET_RAW in the permitted set, and will only enable this capability in the effective set when opening raw sockets.

The CAP_NET_RAW capability in the permissions set can be added to the arp-scan executable with:

setcap cap_net_raw+p /path/to/arp-scan

from arp-scan.

@viccie30 I know it's a long shot but just in case you wrote the patch and just forgot to submit it, I would like to kindly remind you about it.

from arp-scan.

Initial Linux capabilities code has been added to the git branch "capabilities". The plan is to merge this back into the master branch once it is stable.

The current status is:

• configure.ac contains autoconf checks for the presence of libcap support and defines the HAVE_LIBCAP macro to 1 if POSIX capabilities are supported.
• utils.c contains two new functions: limit_capabilities() to limit the process permitted capabilities, and set_capability() which can be used to enable and disable the required capabilities.
• arp-scan.c contains a call to limit_capabilities() as the first statement in main(), and calls to set_capability() at appropriate places around code sections that need to be executed with either root permissions or the CAP_NET_RAW capability.

The code currently compiles and runs on Debian Buster with the libcap-dev package installed, and on FreeBSD 13 which lacks POSIX capabilities. Further testing is required.

Any comments on the capabilities code is welcome.

from arp-scan.

When arp-scan is built with capabilities support and run as root (not just SUID root) it does not bypass file permissions checks, which can cause unexpected "permission denied" errors when writing a pcap file with the --pcapsavefile if UID 0 does not have permission to create or write to the specified file.

Running arp-scan as root (e.g. sudo ./arp-scan) when it has been built with capabilities support will drop all capabilities and only enable CAP_NET_RAW while the packet sockets are opened. This means that running arp-scan as root does not give it any additional capabilities beyond briefly having CAP_NET_RAW - in particular it does not have CAP_DAC_OVERRIDE so it does not bypass file permission checks as might be expected.

This can result in permission denied errors in certain situations where you might expect it to succeed "because it's running as root". For example if we run arp-scan as root from a directory with mode 755 that is not owned by root, an attempt to create a pcap file in that directory will fail because the process lacks CAP_DAC_OVERRIDE and the directory lacks write access for "others".

rsh@bullseye:/tmp/arp-scan-1.9.9$ ls -ld /tmp/arp-scan-1.9.9
drwxr-xr-x 3 rsh rsh 4096 Oct 12 11:15 /tmp/arp-scan-1.9.9

rsh@bullseye:/tmp/arp-scan-1.9.9$ sudo ./arp-scan --pcapsavefile=arp.pcap --localnet
Interface: ens33, type: EN10MB, MAC: 00:0c:29:d3:97:e8, IPv4: 192.168.14.128
pcap_dump_open: arp.pcap: Permission denied

Allowing write access for others makes it work, and creates a file owned by root as expected:

rsh@bullseye:/tmp/arp-scan-1.9.9$ chmod o+w .

rsh@bullseye:/tmp/arp-scan-1.9.9$ sudo ./arp-scan --pcapsavefile=arp.pcap --localnet
Interface: ens33, type: EN10MB, MAC: 00:0c:29:d3:97:e8, IPv4: 192.168.14.128
Starting arp-scan 1.9.9 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.14.1    00:50:56:c0:00:08       VMware, Inc.
192.168.14.2    00:50:56:e4:9a:83       VMware, Inc.
192.168.14.129  00:0c:29:4f:3f:f7       VMware, Inc.
192.168.14.137  00:0c:29:b9:43:1b       VMware, Inc.
192.168.14.254  00:50:56:ed:35:d5       VMware, Inc.

77 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.9.9: 256 hosts scanned in 2.799 seconds (91.46 hosts/sec). 5 responded

rsh@bullseye:/tmp/arp-scan-1.9.9$ ls -l arp.pcap
-rw-r--r-- 1 root root 404 Oct 12 11:35 arp.pcap

This issue does not occur with SUID root because capabilities aware arp-scan will immediately drop SUID with setuid(getuid()) while retaining only CAP_NET_RAW, so it runs with the effective ID of the parent process.

But when actually running as root UID=EUID=0, so setuid(getuid()) has no effect.

I'm not sure if this counts as a regression though, so I'm just leaving it as a comment for now.

from arp-scan.

Implemented in version 1.10.0 https://github.com/royhills/arp-scan/releases/tag/1.10.0

from arp-scan.