Skip to content

Support Linux capabilities for non-root raw packet scanning#3333

Open
ali-keys wants to merge 1 commit into
nmap:masterfrom
ali-keys:master
Open

Support Linux capabilities for non-root raw packet scanning#3333
ali-keys wants to merge 1 commit into
nmap:masterfrom
ali-keys:master

Conversation

@ali-keys
Copy link
Copy Markdown

Nmap previously required root (geteuid()==0) for any scan type that uses raw sockets. On Linux, setcap(8) can grant the necessary access without a full root UID:

  sudo setcap cap_net_raw=ep /usr/bin/nmap

Add have_net_capabilities() to nbase/nbase_misc.c, which reads CapEff from /proc/self/status and tests for CAP_NET_RAW (bit 13). Both NmapOps::Initialize() and NpingOps::Initialize() now set isr00t when either geteuid()==0 or CAP_NET_RAW is effective, suppressing the "You requested a scan type which requires root privileges." error.

CAP_NET_RAW is sufficient for raw sockets and promiscuous capture via PACKET_MR_PROMISC on an AF_PACKET socket. The capability check is Linux-only (#ifdef __linux__); all other platforms retain their existing behaviour.

Nmap previously required root (geteuid()==0) for any scan type that uses
raw sockets. On Linux, setcap(8) can grant the necessary access without
a full root UID:

  sudo setcap cap_net_raw=ep /usr/bin/nmap

Add have_net_capabilities() to nbase/nbase_misc.c, which reads CapEff
from /proc/self/status and tests for CAP_NET_RAW (bit 13). Both
NmapOps::Initialize() and NpingOps::Initialize() now set isr00t when
either geteuid()==0 or CAP_NET_RAW is effective, suppressing the
"You requested a scan type which requires root privileges." error.

CAP_NET_RAW is sufficient for raw sockets and promiscuous capture via
PACKET_MR_PROMISC on an AF_PACKET socket. The capability check is
Linux-only (#ifdef __linux__); all other platforms retain their
existing behaviour.
@nnposter
Copy link
Copy Markdown

This is indeed a great idea. 👍

That said, I believe that it would be better to accept the need for linking with an additional library for the benefit of simpler and more future-proof code. Please take a look at #3356.

@ali-keys
Copy link
Copy Markdown
Author

Wonder why it hasn't been implemented before.
It makes sense to use capability libs, however I thought it's not appreciated to introduce new dependencies.

@nnposter
Copy link
Copy Markdown

Wonder why it hasn't been implemented before.

I do not recall any recent discussion about it. Users are likely happy with what they find at SecWiki. As for myself, I set NMAP_PRIVILEGED=1 in my profile a decade ago and never thought about it since then.

It makes sense to use capability libs, however I thought it's not appreciated to introduce new dependencies.

I agree that new dependencies should not be introduced frivolously but these particular libraries are already in place for many distros by default, which makes it palatable to me.

@ali-keys
Copy link
Copy Markdown
Author

I do not recall any recent discussion about it. Users are likely happy with what they find at SecWiki. As for myself, I set NMAP_PRIVILEGED=1 in my profile a decade ago and never thought about it since then.

Yes, NMAP_PRIVILEGED is fine, but I mean capabilities have been around since the beginning of creation. One expects mature projects to have them adopted.

I agree that new dependencies should not be introduced frivolously but these particular libraries are already in place for many distros by default, which makes it palatable to me.

Yes, you're right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants