Jonathan S. Shapiro wrote:
>
> [Ben Laurie, one of the authors of Apache and also the author of a
> (good) book on Apache, has joined the EROS architects list. He has
> also volunteered, time permitting, to help with an Apache port to
> EROS.]
>
> I've been thinking about CGI scripts under EROS/Apache. A word of
> caution: At this point, I know just enough about apache and CGI
> handling to really mess things up when I screw with the server config.
>
> My understanding of CGI scripts under UNIX is that the web server
> invokes the script with some environment variables set, collects its
> output, does some minor post-processing (calculating length and such),
> and ships the result back to the requestor.
That's about the size of it, except it may set some limits, timeout after a while, and that kind of thing. If the request that invokes the CGI is a POST or PUT the CGI is also handed the body of the request (actually, this may be triggered by there being a body, but that's not particiularly important) on its standard input. This is another place where select() is needed (to avoid a deadlock), or some other appropriate mechanism (if pipes are not infinitely long).
> The security issue with CGI scripts is twofold:
>
> 1. The script is turing-complete, and has access to the file system,
> so there is no telling what it will do.
Even on Unix there is some telling what it'll do, but the point is taken.
> 2. The script runs under the web-server's UID, rather than the
> owner's. This interacts badly with the first issue.
bill1 has already mentioned cgiwrap. Apache has a thing called suexec that does a similar thing, but is rather more secure than cgiwrap.
> Let me try to give an account of how this all should work under an
> EROS-based web server:
>
> First, I assume that the EROS web server should not be limited to
> files. What the web server requires is an object that generates
> output according to a well-defined specification. The server is not
> concerned with how that output is generated. If I write a program and
> stick it in a suitable name space, the program should simply be
> executed (provided suitable protections around resources have been
> assured).
>
> Where filtering is used, I assume that the web server hands to the CGI
> program a read-only copy of the segment it is filtering, if any. The
> program is therefore not in a position to modify the object.
>
> Given these two assumptions, it seems to me that the following
> statements are sound:
>
> 1. If the user has the authority to run the program, and also has the
> authority associate a program with the web server, they have the
> authority to cause the web server to run the program, *regardless of
> what the program does*. In EROS, the program does not run with
> special privileges, so the issue of UID does not apply. If the user
> wants to shoot themselves in the foot that is their problem.
That doesn't sound right, but perhaps it is my unfamiliarity with EROS showing. The user may have authority to run a program, but not to connect it to a socket which goes to the Internet. This would provide a route to bypass that, wouldn't it? I'd hope that the answer to this would be "no, it wouldn't", but how?
> 2. Second, we can imagine a class of "safe" CGI programs. These programs
But it may well be desirable to grant the right to filter without the
right to replace. E.g. I can write a pretty printer for EROS source, but
I can't modify it.
> are:
>
> a) confined
> b) resource bounded, or run off the resources of a
> sponsoring user.
>
> Such a program, if executed at lower priority than the web server, is
> completely safe.
>
> 3. If a user has the write to replace a "file", they have the right to
> install a filter in front of it.
> The model for file handling under EROS, then, is that the web server
> locates the URI-object (the object associated with the URI) to be
> returned and kicks off a "URI-returner" object, passing to that
> returner the URI-object and the TCP connection. The URI-returner
> object invokes the URI-object and takes it's output. It inserts any
> necessary headers and returns the whole bundle to the original
> requestor.
Cheers,
Ben.
-- Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache