httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: Possible security enhancement to apache server
Date Tue, 26 Jun 2001 01:29:12 GMT
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
>
>
>


Mime
View raw message