linux security - May 1998 - Configuration for binding to "secure" ports?

[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

On Thu, 28 May 1998, Lamar Owen wrote:
> [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]
You can modify the application auto-magically by LD_PRELOAD''ing a
library
that overrides libc bind() with something dup2()''ing the pre-bound
socket. :)

Well, you could also modify bind() to pass the socket (using BSD-like
unix-domain socket magic) to a privileged "binder daemon" and let it
decide whether you are allowed to bind it to the given port--and do it
itself if you are.
> 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).
A patch for 2.0.x has been published in one of the recent issues
of Phrack that allows processes running under special gids to perform
privileged socket operations.

<quote>

GID 16 : a program running with group 16 privileges can bind to a
         < 1024.  This allows programs like: rlogin, rcp, rsh, and ssh
         to run setgid 16 instead of setuid 0(root).  This also allows
         servers that need to run as root to bind to a privileged port
         like named, to also run setgid 16.

</quote>

I am running named this way.


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]

Lamar Owen writes:
> 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.
[...]
> reasons prohibit me at this time.  So, I am currently stuck at 2.0.x,
> which has no such ''capabilities'' (bad pun).
I''ve written a "socket filesystem" for 2.0 that lets you set
user/group and permissions on ports less than 1024 simply by doing
things like
    chown named /sockfs/53
    chown ldap /sockfs/389
There''s a small kernel patch (which changes the "check for
<1024"
socket bind test to callout to a separate function) and a sockfs.o
filesystem module. You do
    insmod sockfs.o
    mount -t sockfs sockfs /sockfs
and then the appropriate "write" persmission bit on the (fake) file
/sockfs/n determines whether owner/group/other can bind to port n.
It''s available from
    ftp://ftp.ox.ac.uk/pub/linux/sockfs-a1.tar.gz
and is only 6K. It''s alpha1 as its name implies and only lightly
tested but it''s really very simple.

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

On Fri, 29 May 1998 11:26:37 +0200, Pavel Kankovsky
wrote:
> Well, you could also modify bind() to pass the socket (using BSD-like
> unix-domain socket magic) to a privileged "binder daemon" and let
it
> decide whether you are allowed to bind it to the given port--and do it
> itself if you are.
I''ve toyed with this idea for some time... 2.1 offers a feature by
which the kernel passes your uid/gid to the unix socket peer upon connect.
This neatly solves the problem of authenticating anyone connecting to
a unix socket.

While the new capabilities stuff definitely does it better for binding to
a privileged port, other services (e.g. opening a modem port; writing
utmp) might still benefit from this.

Olaf
-- 
/d{def}def/D{dup}d/X{exch}d/L{length}d/-{sub}d/+{add}d/R{D D 0 ge X 26 le and}d
/C{13 + 26 mod}d/_{D L string/. X d . cvs 0 X L 1 X 1 -{D . X get 65 - R{C}{32
- R{C}if 32 +}ifelse 65 + . 3 1 roll put}for .}d/N{_ cvn}d/x{N cvx exec}d
/reebeqvpg x/haqrsvarq N{cvlit _ show}put 240 360 /zbirgb x/Uryirgvpn N
/svaqsbag x 12/fpnyrsbag x/frgsbag x bxve@zbanq.fjo.qr/fubjcntr x

>You can modify the application auto-magically by LD_PRELOAD''ing a
library
>that overrides libc bind() with something dup2()''ing the pre-bound
socket.
:)
>
>Well, you could also modify bind() to pass the socket (using BSD-like
>unix-domain socket magic) to a privileged "binder daemon" and let
it
>decide whether you are allowed to bind it to the given port--and do it
>itself if you are.

Hmmm... This addresses my primary concern, of which I wasn''t really
clear --
the less programs running as root, the less chance a misconfiguration has of
overwriting root-run executables with Trojan code.

I realize that setting file modes, et al can help alleviate much of the
issue (stuff like, the webserver run user should not own the webserver
executable, etc), but, to me, that''s the long way around.  Why not
simply
not have the executable run as root in the first place, greatly simplifying
the task of securing it?

The more I learn about ''capabilities'' the more I like them....
>> 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
[snip]
>A patch for 2.0.x has been published in one of the recent issues
>of Phrack that allows processes running under special gids to perform
>privileged socket operations.

http://www.phrack.com/52/P52-06 is where this info is.  Careful with some of
the patches.....

Lamar Owen
WGCR Internet Radio

Olaf Kirch wrote:
> 
> On Fri, 29 May 1998 11:26:37 +0200, Pavel Kankovsky wrote:
> > Well, you could also modify bind() to pass the socket (using BSD-like
> > unix-domain socket magic) to a privileged "binder daemon"
and let it
> > decide whether you are allowed to bind it to the given port--and do it
> > itself if you are.
> 
> I''ve toyed with this idea for some time... 2.1 offers a feature by
> which the kernel passes your uid/gid to the unix socket peer upon connect.
> This neatly solves the problem of authenticating anyone connecting to
> a unix socket.
> 
> While the new capabilities stuff definitely does it better for binding to
> a privileged port, other services (e.g. opening a modem port; writing
> utmp) might still benefit from this.
I appologize for the interruption but you are forgetting that Linux has
capability lists, which means that they are of limited length, because
you don''t want to spend too much time and resources checking the
authority at a very fine grained level.

Your idea could be done quite easily however on a pure capabilities
based system, because the time that is spent checking the authority is a
constant O(0) or O(1) (depending on the problem and implementation).
Unfortunatelly, capability lists and (pure) capabilities are not the
same. They are actually two very different approaches, one of which is
in use today and the other is a better performer in all respects.

It has been proven that pure capability systems can solve some very
fundamental problems of information security, such as the ''confinement
problem'' or the problem of separating the authority from the identity
of
the object, while virtually no progress has been made with any of the
lists approaches (such as access control lists or capability lists)
within the last 20 years. It is so that while we can have mutually
suspicious objects working securely in the same environment (which is
required for credit card processing facilities for example), we rather
choose to have inefficient systems that have been stuffed on us 20 years
ago by large monopolist companies (that can''t prevent that your data
isn''t compromised by your younger sister (older brother if you choose
capability lists)).

UNIX has changed before and will change again, I hope.

Andrej

-- 
Andrej Presern, andrejp@luz.fe.uni-lj.si