Nmap Development mailing list archives

The difficulty of running Nmap with privileges on Mac OS X


From: David Fifield <david () bamsoftware com>
Date: Sat, 17 May 2008 19:32:44 -0600

Hi,

I've been been working on getting the Mac OS X packages ready for a
standard release. If you missed the test releases, you can get the
latest one at

http://nmap.org/dist/nmap-4.62-test7.dmg

The last major impediment is getting Zenmap to run Nmap with elevated
privileges so it can do more than a connect scan. That has turned out to
be rather difficult. Here are a few things I've considered and what's
good and bad about them.

1. Use Authorization Services and the Python interface to them
(http://undefined.org/python/#Authorization) to run the entire
application as root using AuthorizationExecuteWithPrivileges. You would
see "Zenmap requires that you type your password." when you start the
program. This only sets the effective UID, so GTK+ thinks it's running
setuid and refuses to run (see http://www.gtk.org/setuid.html). This can
be worked around by setting the real UID when the application starts up.
The program will run as if it were being run by root; i.e.,
configuration files would go in /var/root/.zenmap.

2. Use AppleScript to run the entire application as root using a script
like
        osascript -e 'do shell script "./zenmap" with administrator
privileges'
This has the disadvantage that the authentication dialog shows
"osascript requires that you type your password." That could maybe be
fixed by embedding the call in a binary. This has all the limitations of
method 1, except that it sets both the real and effective UIDs so GTK+
doesn't complain.

3. Use Authorization Services to run just the Nmap commands as root. The
user would authenticate once per session. This is really the ideal
solution, because it limits the amount of code that runs privileged, and
Zenmap runs as a real user, with files in their own home directory.
Unfortunately, the function AuthorizationExecuteWithPrivileges doesn't
give us much information about the child process, not even a PID. This
means that we can't kill the Nmap process when a scan tab is closed.
However, this may not be such a huge limitation.

4. Build a setuid helper program just for executing Nmap. The user would
authenticate as normal and then exec the helper, which would in turn
exec nmap. The helper would check the authorization before running, so
it couldn't be used by just anyone to run Nmap. This is basically what
AuthorizationExecuteWithPrivileges does, execing a setuid program called
/usr/libexec/security_authtrampoline, except it would be written to make
the PID recoverable. This is a little tricky because you have to convert
the authorization into an "external form" so the helper can read it and
inherit it. I hesitate to start shipping setuid binaries.

Any other ideas?

How is everyone running Zenmap on other varieties of Unix? With sudo
from the shell? If all this is too much I can give up on the Zenmap
application bundle and just install it as a command-line utility, which
will make it work the same as on the Unixes.

Does anyone know of any other free Mac OS X software that has to run a
command with elevated privileges? If you do please tell me because they
may have already solved the problem.

David Fifield

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: