Re: [Patch] Automatically switch to privileged when Nmap has required capabilities

[Daniel Miller <bonsaiviking () gmail com>]

Just some initial thoughts:

On Wed, Aug 13, 2014 at 6:22 AM, Jay Bosamiya <jaybosamiya () gmail com> wrote:

> Until now, even if Nmap had capabilities (CAP_NET_RAW, CAP_NET_ADMIN,
> CAP_NET_BIND_SERVICE), it would not be able to use them unless
> --privileged was specified.

For reference, this is a Linux-specific feature that has been supported in
the Linux kernel for a long time. Here are some references:

* FAQ from 1999 (kernel 2.2) -
https://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0.2.txt
* capabilities(7) man page - http://linux.die.net/man/7/capabilities
* Security implications -
https://forums.grsecurity.net/viewtopic.php?f=7&t=2522&sid=c6fbcf62fd5d3472562540a7e608ce4e#p10271


>   * If the executable itself has been granted the capabilities (using
>     `sudo setcap cap_net_raw,cap_net_admin,cap_net_bind_service+eip
>     nmap`) and if Nmap is run as root, then tell the user that root is
>     unnecessary, drop privileges and switch to the user "nobody/nogroup".

This can be done even if the *file* capabilities are not in place, because
root can grant the *process* capabilities before dropping privilege. This
may be what is causing you problems: Try using the PR_SET_KEEPCAPS
operation with prctl (http://linux.die.net/man/2/prctl)


>   * When installing Nmap through "make install", we can grant the
>     capabilities (by default) so that users can use privileged features
>     without the security risk of running as root.

This is not a good idea, because these capabilities are protecting
privileged operations that admins may not want to grant to regular users.
Specifically, being able to sniff network traffic, possibly being permitted
to manage network interfaces, etc. On the other hand, we could ship a
simple script to do this, or create a new make target, "make setcap" or
something, to make it easier for people to do it on their own.

  * If the user specifies --unprivileged, drop the user to
>     "nobody/nogroup" whenever possible so that it is more secure.
This sounds good. We should probably also support options to choose the
UID/GID to drop privileges to, and provide an option *not* to drop
privileges. These options could be abused, though, for a setuid program
(though we still would not recommend installing Nmap setuid until it had
been thoroughly vetted), so we'll have to decide how to handle things there.


Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/