Possible security enhancement to apache server

[David Campbell <da...@pastornet.net.au>]

Hi,

I would like to discuss with anybody who knows the internals of the
software the viability of an Apache server change along the following lines.
Verbose mode on.

Apache is mostly started by system scripts at boot time, and as such, is
started as root.  From there, it can change uid and gid down to user
nobody or whoever.
But in a situation where apache has to be restarted in a control-centre
environment where application services are monitored, apache still
needs to be started as root because it needs to be able to bind to low
ports (Unix requirement).  BUT if you want to run the control-centre
as a non-root user, the only option it would seem is to have some
sort of setuid program to start apache as root.  Then, if the control-centre
has the requirements to be able to write the apache config files, then
you're in a situation where the user under which apache runs has both
the ability to launch apache as root and also to reconfigure apache.
Together, this means that the user has the ability to get a root shell on
the system by configuring apache to do things that it shouldn't.

This opens up a can of worms with respect to security.  Many people
do this anyway.

I would like to propose a configurable option to Apache's bind process
that does something along the following lines.  The idea is this:  allow non-root
user processes to bind to low ports, but do it in a well-defined and fully
controllable way.  How?  Read on.

The technique is as follows:  instead of calling bind() directly from
Apache, optionally (given configuraiton options) invoke a function
delegate_bind() which has the same parameters as bind(), which if
binding to low ports, internally does a fork() and execs a setuid
root program that inherits the socket from its parent process and
does the bind of the socket to a low port.  Because the socket in
the child process is the same as the socket in the parent process,
the bind done in the child process does bind the socket in the
parent process.  The child process then exits returning status etc.
This setuid program can check a configuration file in /etc to see
whether the invoking user is allowed to do the bind to the particular
port, and deny them if not allowed.

I have a working implementation of the above (not integrated into
apache) at:
    http://www.aaa.net.au/campbell/delegate_bind.tar.gz   (3k)

I'm quite happy to try to integrate the above into Apache sources,
but would there be interest from the powers that be to include the
above into the apache distribution?

Does anybody have any comments about the implications
of the above?

Are there any complexities that I could possibly be not seeing?

--
Regards,
-- Dave Campbell
   PHONE AUS  07 3216 6015
   PHONE INTL +61 7 3216 6015

Re: Possible security enhancement to apache server

[David Campbell <da...@pastornet.net.au>]

Ian,

Like I said, the apache config files need to be writable by the control-centre
so they'd have to be writeable by the uid under which the control-centre runs.

Then I guess that apache could be launched from sudo and then change down to a different
uid that could read the config files as well.  Sounds ok.

But given that the control-centre is having to invoke sudo under programmatic control,
sudo would have to be configured with no password, because it I presume that it requires
passwords to be read from a tty, and even if it were to use a password, it must be stored
somewhere.

Then, that means that the uid under which the control-centre runs has write access to the
apache config files and the ability to launch apache as root using sudo, which means that
they could alter the apache config to do something it shouldn't, and start up apache as root,
and there you go, they can easily get a root shell.

-- Dave

Ian Holsman wrote:

> Hi David,
> why not have the config files owned by another user/group (eg webops)
> and have a some scripts runnable by sudo? (start/restart/stop)
>
> that should provide the level of control you need.
>
> > This opens up a can of worms with respect to security.  Many people
> > do this anyway.
> >
> > I would like to propose a configurable option to Apache's bind process
> > that does something along the following lines.  The idea is this:  allow non-root
> > user processes to bind to low ports, but do it in a well-defined and fully
> > controllable way.  How?  Read on.
> >
> > The technique is as follows:  instead of calling bind() directly from
> > Apache, optionally (given configuraiton options) invoke a function
> > delegate_bind() which has the same parameters as bind(), which if
> > binding to low ports, internally does a fork() and execs a setuid
> > root program that inherits the socket from its parent process and
> > does the bind of the socket to a low port.  Because the socket in
> > the child process is the same as the socket in the parent process,
> > the bind done in the child process does bind the socket in the
> > parent process.  The child process then exits returning status etc.
> > This setuid program can check a configuration file in /etc to see
> > whether the invoking user is allowed to do the bind to the particular
> > port, and deny them if not allowed.
> >
> > I have a working implementation of the above (not integrated into
> > apache) at:
> >     http://www.aaa.net.au/campbell/delegate_bind.tar.gz   (3k)
> >
> > I'm quite happy to try to integrate the above into Apache sources,
> > but would there be interest from the powers that be to include the
> > above into the apache distribution?
> >
> > Does anybody have any comments about the implications
> > of the above?
> >
> > Are there any complexities that I could possibly be not seeing?
> >
> > --
> > Regards,
> > -- Dave Campbell
> >    PHONE AUS  07 3216 6015
> >    PHONE INTL +61 7 3216 6015
> >

--
Regards,
-- Dave Campbell
   PHONE AUS  07 3216 6015
   PHONE INTL +61 7 3216 6015

Re: Possible security enhancement to apache server

[Ian Holsman <ia...@cnet.com>]

On 26 Jun 2001 10:01:14 +1000, David Campbell wrote:
> Hi,
> 
> I would like to discuss with anybody who knows the internals of the
> software the viability of an Apache server change along the following lines.
> Verbose mode on.
> 
> Apache is mostly started by system scripts at boot time, and as such, is
> started as root.  From there, it can change uid and gid down to user
> nobody or whoever.
> But in a situation where apache has to be restarted in a control-centre
> environment where application services are monitored, apache still
> needs to be started as root because it needs to be able to bind to low
> ports (Unix requirement).  BUT if you want to run the control-centre
> as a non-root user, the only option it would seem is to have some
> sort of setuid program to start apache as root.  Then, if the control-centre
> has the requirements to be able to write the apache config files, then
> you're in a situation where the user under which apache runs has both
> the ability to launch apache as root and also to reconfigure apache.
> Together, this means that the user has the ability to get a root shell on
> the system by configuring apache to do things that it shouldn't.
> 
Hi David,
why not have the config files owned by another user/group (eg webops)
and have a some scripts runnable by sudo? (start/restart/stop)

that should provide the level of control you need.


> This opens up a can of worms with respect to security.  Many people
> do this anyway.
> 
> I would like to propose a configurable option to Apache's bind process
> that does something along the following lines.  The idea is this:  allow non-root
> user processes to bind to low ports, but do it in a well-defined and fully
> controllable way.  How?  Read on.
> 
> The technique is as follows:  instead of calling bind() directly from
> Apache, optionally (given configuraiton options) invoke a function
> delegate_bind() which has the same parameters as bind(), which if
> binding to low ports, internally does a fork() and execs a setuid
> root program that inherits the socket from its parent process and
> does the bind of the socket to a low port.  Because the socket in
> the child process is the same as the socket in the parent process,
> the bind done in the child process does bind the socket in the
> parent process.  The child process then exits returning status etc.
> This setuid program can check a configuration file in /etc to see
> whether the invoking user is allowed to do the bind to the particular
> port, and deny them if not allowed.
> 
> I have a working implementation of the above (not integrated into
> apache) at:
>     http://www.aaa.net.au/campbell/delegate_bind.tar.gz   (3k)
> 
> I'm quite happy to try to integrate the above into Apache sources,
> but would there be interest from the powers that be to include the
> above into the apache distribution?
> 
> Does anybody have any comments about the implications
> of the above?
> 
> Are there any complexities that I could possibly be not seeing?
> 
> --
> Regards,
> -- Dave Campbell
>    PHONE AUS  07 3216 6015
>    PHONE INTL +61 7 3216 6015
> 

Re: Possible security enhancement to apache server

[dean gaudet <dg...@arctic.org>]

i did something similar ages ago... and i think manoj did some followon
work to my patch.  my idea was to use a wrapper much like innd uses, just
to open the socket.

if you look at <http://arctic.org/~dean/apache/1.3/arctic_mods_v2.patch>
and search for "pre_opened_socket", "permanent_listeners", and
"listenwrap" you should see the bits and pieces of the solution i was
trying out for the listening descriptor(s).  i gave up maintaining it
though...

another complexity you need to deal with is logging -- ideally you want
the web user to be able to append to the currently open logs and that's
it; no ability to delete/rename/truncate the logs.

-dean

On Tue, 26 Jun 2001, David Campbell wrote:

> Hi,
>
> I would like to discuss with anybody who knows the internals of the
> software the viability of an Apache server change along the following lines.
> Verbose mode on.
>
> Apache is mostly started by system scripts at boot time, and as such, is
> started as root.  From there, it can change uid and gid down to user
> nobody or whoever.
> But in a situation where apache has to be restarted in a control-centre
> environment where application services are monitored, apache still
> needs to be started as root because it needs to be able to bind to low
> ports (Unix requirement).  BUT if you want to run the control-centre
> as a non-root user, the only option it would seem is to have some
> sort of setuid program to start apache as root.  Then, if the control-centre
> has the requirements to be able to write the apache config files, then
> you're in a situation where the user under which apache runs has both
> the ability to launch apache as root and also to reconfigure apache.
> Together, this means that the user has the ability to get a root shell on
> the system by configuring apache to do things that it shouldn't.
>
> This opens up a can of worms with respect to security.  Many people
> do this anyway.
>
> I would like to propose a configurable option to Apache's bind process
> that does something along the following lines.  The idea is this:  allow non-root
> user processes to bind to low ports, but do it in a well-defined and fully
> controllable way.  How?  Read on.
>
> The technique is as follows:  instead of calling bind() directly from
> Apache, optionally (given configuraiton options) invoke a function
> delegate_bind() which has the same parameters as bind(), which if
> binding to low ports, internally does a fork() and execs a setuid
> root program that inherits the socket from its parent process and
> does the bind of the socket to a low port.  Because the socket in
> the child process is the same as the socket in the parent process,
> the bind done in the child process does bind the socket in the
> parent process.  The child process then exits returning status etc.
> This setuid program can check a configuration file in /etc to see
> whether the invoking user is allowed to do the bind to the particular
> port, and deny them if not allowed.
>
> I have a working implementation of the above (not integrated into
> apache) at:
>     http://www.aaa.net.au/campbell/delegate_bind.tar.gz   (3k)
>
> I'm quite happy to try to integrate the above into Apache sources,
> but would there be interest from the powers that be to include the
> above into the apache distribution?
>
> Does anybody have any comments about the implications
> of the above?
>
> Are there any complexities that I could possibly be not seeing?
>
> --
> Regards,
> -- Dave Campbell
>    PHONE AUS  07 3216 6015
>    PHONE INTL +61 7 3216 6015
>
>
>