Configuration for binding to "secure" ports?

[Lamar Owen <lamar owen wgcr org>]

[Note to R. Wolff -- thanks for the pointers and the program.  As I
understand its workings, it would run as root and bind a listen port
to a particular program -- with a list being supplied in
/etc/portadmin or other file.  Basically, a listen wrapper.  Hopefully
this message will address your cleanup concerns in my previous
message.  Thanks.  Also, you may want to provide a moderator's note
pointing out your program in the works.  Speaking of which, since you
sent me that copy I am assuming that I may use and test it, but not
distribute it (your copyright prohibits copying) You're code is very
clear -- I could have written a program to do this, but
it would have taken me far longer than 40 minutes.

I thought about mentioning a port-wrapper in more detail in the first
message, but, since my network programming skills are not top-caliber,
assumed a program could not pass a bound socket to a child process --
in hindsight an ignorant assumption.  So, I have included the basic
algorithm in this post.  Feel free to remove if you need to.]  

[mod: As you can read here, I wrote a short (currently 100 lines)
program that binds to a port and then execs a prespecified deamon
under a specified uid. Now my head is clear, almost the same can be
achieved with inetd. Moreover, as the application has to be modified
to accept the socket using some mechanism, you could just as well
modify it to drop root privs after opening the socket. Oh well. --REW]


[---- Start of actual post -----]

Today while going over my security setup, I noticed that quite a few  of my
security issues revolved around secure ports -- that is, ports under 1024.

I began to think -- what if there was a way to configure the kernel to
allow a non-root program to listen on a particular "secure" port --
then I wouldn't have to start various and sundry network daemons as
root, just to have them seteuid to another user after acquiring the
port.  My security issues involving those programs would not be quite
as great -- at least I wouldn't have to worry about root compromises
due to a buggy root-running daemon (such as named, which, in its
current incarnation as BIND 4 doesn't give up root privs after binding
the port...).

After sending a draft of this message to the linux-security list, I
received a highly informative "message rejected" e-mail from Rogier
Wolff pointing out that the newest kernels in the 2.1 series have
'capabilities' -- one of which allows binding to secure ports by
certain processes.  I look forward to 2.2, which should incorporate
such features. I would upgrade to a 2.1.x kernel, but stability
reasons prohibit me at this time.  So, I am currently stuck at 2.0.x,
which has no such 'capabilities' (bad pun).

The general idea is to allow a configuration file (or set of
parameters, or use an external portadmin program) to allow certain
users to listen on secure ports: ie, 'portadmin 80 aolserver' would
issue a command to the kernel to allow user aolserver to run a daemon
listening on port 80, if no program already had port 80.  Or, even
better, 'portadmin 80 aolserver /usr/local/AOLserver/bin/nsd', further
restricting that port to a particular executable.

Another way would be a listen wrapper -- which could, I am told, be
written to run in userspace in about 40 minutes.  Such a program would
read a config file containing the port to bind, the userid under which
to run, and a program to exec.  It would then bind the port, seteuid
to the uid desired, then exec the program.  Call it port-wrapper.  It
would, of course, HAVE to run as root, meaning special pains would
have to be taken to make it secure.  [mod: but there being less than
200 source-lines, a -=full=- source code review is easy. -- REW]

Since this is linux-security, I am curious as to just WHY ports under
1024 have to be so restricted?  (I know the history -- I read it in
the devil book.)  Or, to put it another way, which opens more holes --
not having "secure" ports (with restrictions) or having to deal with
setuid root exploits?  Of course, there would be security issues
dealing with the portadmin program or config file, but I think those
would be minor compared to what can be done with, say, a broken named
running as root.

Lamar Owen
WGCR Internet Radio