httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: setuid control WITHOUT running as root
Date Sun, 02 Jun 1996 17:33:05 GMT
> > 4) Unfortunately, looking over the wrapper itself, if you do install
> >    it with the suid bit on, I do see a problem --- if you can get a
> >    process running as 'www', and this wrapper has been installed
> >    suid-root, you can then run the wrapper yourself with argv[1] of
> >    root and wreak your will.  Possible ways of getting such a process
> >    include *non*-suid CGI, and putting a trojan-horse command where it
> >    will get run by a maintenance job.  (Ah, the games you can play
> >    with 'uucp'...).  At any rate, it seems a little more paranoia
> >    is in order here on the part of the wrapper itself.
> This is one of the major reasons that CGIwrap does all the checks itself to
> verify that the script should indeed be allowed to run... It has to be
> configured with information such as who the http server is running as, and
> what it considers acceptable in CGI scripts. For example, it won't run a
> setuid script, or a script in "nneul"'s directory that is owned by someone
> else.

Unfortunately, CGIwrap requires a level of knowledge of URL syntax
that many of our customers do not understand. Most of them are doing
well to ftp a file to the server. Making it as easy as possible is
important. I also want to have control on a per/server basis of what
that exec ID is. As far as I know, CGIwrap does not allow that.

> I personally think it would be better to design any CGI modifications
> (along the lines of suCGI) without thinking about setuid purposes...

My approach is really no different than that of mod_sucgi. One advantage
of my approach is that it centralizes the exec code where some of the
initial safety checks are done. It is then easy for anything else in the
server to use call_exec() to do the job.

> A better approach would be to design along the lines of "CGI execution
> filter". Basically saying something like: "Yes, you can run a cgi script in
> this directory, but it has to be executed through this filter first."

> The filtering could be special purpose setuid tools, such as the backend
> for sucgi or CGIwrap, or could be other tools such as usage
> accounting/filtering/etc.

Much of the problem in getting something like this accepted into the
core is the complexity of the implementation. Can you do what you propose
in a more simple way than what I have?

> This would isolate the Apache server from the major security concerns of
> running setuid scripts and such, but at the same time would allow that
> functionality to be added much more easily with add-on tools produced by
> other people.

How does my patch fail to address that?

> This could be extended to be thought of as a "data access filter" - where
> accessing certain data could be passed through an external routine to be
> accessed.

There is already a fair amount of data access control in the server.
How can we increase that without complicating the server more, or
needing to include a very complicated wrapper?

View raw message