Mike Bilow [mailto:mikebw@colossus.bilow.com] wrote:
> This is a critically important point, and it is good that it was made.
>
> However, since the web server necessarily runs at fairly low privilege --
> the default is "nobody" but a proper system defines a special user
> account (such as "www-data" in the case of Debian) -- the configuration
> files such as "OpenSRS.conf" must necessarily be readable to users with
> fairly low privilege. There are actually better ways of securing the file
> than by playing suid games in Apache, but the end result is that anyone
> who has privileges to run CGI on the web server cannot be stopped from
> getting read access to the file.
>
> It is, in my opinion, impossible to secure a file that must be accessible
> to CGI under the web server against access by other users who have login
> accounts or the ability to run arbitrary CGI processes on the machine. If
> you are selling public access web hosting, for example, you would be
> insane to run OpenSRS CGI (and e-commerce applications generally) on the
> same machine that is used for customer sites. The only proper way to do
> this is to use two machines, one a secure machine for OpenSRS and the
> other a sacrifical machine for customer access.
>
> -- Mike
Completely wrong. When you play "setuid games" you make each user's CGIs run
under their username. (Or rather you give them the ability to run the CGIs they
want as their username) This way userA can have privileged data and userB can
have privileged data and everyone's data is secure.
Believe me, I know. I've spent quite a bit of time allowing my users to
securely execute CGI scripts and have private data. I've thoroughly hacked up
cgi-wrap and discovered it was not the solution I wanted. Then I messed around
with suexec creating a 1600 line patch to make it do exactly what I want for my
users.
- David Harris
Principal Engineer, DRH Internet Inc.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT