inndstart security model fix
rra at stanford.edu
Tue Sep 7 13:29:40 UTC 1999
I think I've pretty much convinced myself that inndstart currently isn't
secure, although I don't think one can get a root exploit out of it. I do
think that one can probably use it to leverage news group access into news
user access without too much difficulty, though.
I believe that the following security model will prevent that, or at least
make it extremely difficult. I'm working on implementing it right now.
Any strong objections or critique?
Note that this changes the historical workings of inndstart: Formerly,
anyone in the news group could use inndstart to start innd. Under these
changes, you would have to actually be the news user. Since other odd
things happen with helper programs if you run rc.news as someone other
than news, I think this change is acceptable, but for obvious reasons I'm
not proposing it for the STABLE branch.
Note also that with this change, inndstart won't bind to any low-numbered
(privileged ports) other than 119. That means that in order to run a
second news server or run a news server on an alternate port, it would
have to run on a high-numbered port.
/* $Id: inndstart.c,v 1.21 1999/09/07 10:01:50 rra Exp $
** Open the privileged port, then exec innd.
** inndstart, in a normal INN installation, is installed setuid root and
** executable only by users in the news group. Because it is setuid root,
** it's very important to ensure that it be as simple and secure as
** possible so that news access can't be leveraged into root access.
** Fighting against this desire, as much of INN's operation as possible
** should be configurable at run-time using inn.conf, and the news system
** should be able to an alternate inn.conf by setting INNCONF to the path
** to that file before starting any programs. The configuration data
** therefore can't be trusted.
** Our security model is therefore:
** - The only three operations performed while privileged are determining
** the UID and GID of NEWSUSER and NEWSGRP, setting system limits, and
** opening the privileged port we're binding to.
** - We can only be executed by the NEWSUSER and NEWSGRP, both compile-
** time constants; otherwise, we exit. Similarly, we will only setuid()
** and setgid() to the NEWSUSER and NEWSGRP. This is to prevent someone
** other than the NEWSUSER but still able to execute inndstart for
** whatever reason from using it to run innd as the news user with bogus
** configuration information, thereby possibly compromising the news
** - The only port < 1024 that we'll bind to is 119. This is to prevent
** the news user from taking over a service such as telnet or POP and
** potentially gaining access to user passwords.
** This program therefore gives the news user the ability to revoke system
** file descriptor limits and bind to the news port, and nothing else.
** Note that we do use getpwent() to determine the UID of NEWSUSER, which
** potentially opens an exploitable hole on those systems that don't
** correctly prevent a user running a setuid program from interfering with
** the running process (replacing system calls, for example, or using
** things like LD_PRELOAD). It may be desireable to map those to UIDs at
** configure time to prevent this attack.
Russ Allbery (rra at stanford.edu) <URL:http://www.eyrie.org/~eagle/>
More information about the inn-workers