httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Shea <>
Subject Re: Contribution: SuEXEC Options
Date Sun, 15 Nov 1998 16:38:05 GMT
On Sun, 15 Nov 1998, Jim Jagielski wrote:
> My only comment on suEXEC is that, IIRC, it was designed to be as small
> and as "light" as possible. Sure, that made it somewhat restrictive and
> "less powerful" but easier to check out, security-wise. If a hole
> exists in suEXEC, it gets placed right on Apache's door step, and that's
> another reason why it was designed the way it was: to reduce that possibility.
> To increase the "power" and hence complexity of suEXEC does open Apache
> to just this scenario.
> How about having these patches under 'contrib' or something a little
> bit more "removed" from the official source? There are other third-party
> programs (the best IMO being 'cgiwrap') which provide the extended capability
> and maybe this could be suEXEC+, which would also be 3rd party.

I have worked under cgiwrap and while it does work as advertised, it
is an ugly thing to stuff into your html.  Please let's do something
a bit more elegant...

Perhaps an intermediate path might be for Apache to export some
information to the suexec wrapper, and then oec and I can
hack up suexec to use that information however we want to,
and distribute our results independently.  Maybe that's what
Randy T. was saying?  Export the hooks and look the other way ;)

It sounds like there are two basic approaches:

1) Option SuEXEC -- The server config determines in what directories
    suexec gets called to do cgi/include forks.  All other configuration
    info lives in a suexec.conf file.  Clearly there's not much that
    can be spoofed here.  This is incompatible with the current
    version of suexec.

2) UserID/GroupID -- The server supports directives which set the
    uid/gid to use in a given directory, implying that suexec gets used
    in that directory (assuming uid/gid aren't the server_uid/gid).  The
    uid/gid can be spoofed, but if suexec checks the uid/gid of the
    files to be exec'd and the directories those files are in and the
    write permissions on the files etc., a uid/gid spoof doesn't win
    that attacker anything.  I _think_ this is compatible with the
    current version of suexec?

I can live comfortably with either approach.


p.s. My patches (suexecflex in contrib/) for 1.3b3 (which I was
about to re-distribute for 1.3.3 until I discovered this much-needed
debate going on!) are of type (2).  The approach I took is to specify
the uid/gid in the mod_cgi module (as in mod_cgi_sugid, if anuone
rmembers that module hack), and the suexec.conf file has a list of
directories suexec is allowed to work in.  I'm happy with the suexec
side of the solution, but the server side is lacking in generality --
I'd like a solution that worked for both mod_include and mod_cgi,
and preferably didn't require hacking both of them to support UserId/
GroupID directives.  Perhaps an extension of the existing User/Group
directives into Directory and Location?

> ===========================================================================
>    Jim Jagielski   |||   |||
>             "That's no ordinary rabbit... that's the most foul,
>             cruel and bad-tempered rodent you ever laid eyes on"

Gary Shea                             
Salt Lake City            

View raw message