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

[Daniel Miller <bonsaiviking () gmail com>]

On Mon, Aug 18, 2014 at 11:18 AM, Patrick Donnelly <batrick () batbytes com>
wrote:

> On Sun, Aug 17, 2014 at 9:31 AM, Jay Bosamiya <jaybosamiya () gmail com>
> wrote:
> > If capabilities exist for the nmap executable file, then use them
> > If --unprivileged is used, then drop privileges (and also drop
> capabilities)
> > If run as root, then drop privileges without losing the capabilities
> that it
> > needs
> > The user to drop to is currently fixed to "nobody" but the code has been
> > written in such a way that it will be trivial to add a CLI option to
> choose
> > the user to drop to (just have to do a `o.drop_user = strdup(optarg);`).
> I
> > have currently not added such a CLI option because of being unsure of the
> > security implications of this.
> > Two new make targets
> >
> > "make setcap" grants capabilities to the nmap executable in the same
> > directory
> > "make setcap-install" grants capabilities to nmap executable in the
> > installation path
> >
> > Feedback is welcome as always :)
>
> Great work on this patch Jay! One last comment/question: how does this
> change effect opening various files at startup, especially log files?
>
> e.g. if as root I do:
>
> $ pwd
> /root
> $ nmap -A localhost -oN nmap.txt
>
> will that fail because nmap can't open nmap.txt after dropping
> privileges? What about opening script files/libraries?
>
> Do we/should we start opening these files ahead of time?

Additionally, David brought up that some NSE scripts (whois-ip, I believe
was the example) have the ability to save to output files, which would mean
opening them later than privileges were dropped. I think at a minimum we
need to make sure our error messages reflect that this may be the cause of
a problem in opening a file.

Another thought would be to explicitly limit capabilities to the required
set, rather than just letting the setuid call do it. This way, we could
support either of two workarounds:

1. Expose the uid to the CLI as you suggested, letting the user do
--drop-user 0 or --drop-user root to avoid changing the UID at all. This
means that a successful exploit against Nmap would be able to re-enable all
capabilities, negating the security benefit, but it would at least be there
for the majority of cases, or

2. All of 1, plus we default to not change the UID. This means complete
backwards-compatibility for now, with the user able to choose to drop
privileges if they want to. Coupled with appropriate warnings, this could
give users some time to adjust to the idea before we would make dropping
privileges the default in a future release.

I am just brainstorming some possible solutions; I know that there are
major downsides to each of these, but we need discussion to decide which
way to go.

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