Mike Bilow <mikebw@colossus.bilow.com> wrote:
> In the case of OpenSRS, for example, "OpenSRS.conf" should be protected
like this:
> <Files OpenSRS.conf>
> order allow,deny
> deny from all
> </Files>
This ensure that apache refuses to give access to OpenSRS.conf, but a
compromised CGI will read it with no restrictions.
> In general, files such as "OpenSRS.conf" which are intended to be read by
> the executing CGI and never actually sent to a browser over the wire
> should be maintained outside of the document root.
Absolutely, but this still doesn't stop the compromised CGI.
To summarise, IMHO, using Apache's access control is necessary, but
certainly not sufficient.
David Denney <daud@dimensional.com> wrote:
> If you allow users to login to your secure server, that is even scarrier
to me !!!
> Local users are a security problem for ANY system. I restrict my users to
a single shell machine,
> and they have no access to any other machines, directly.
This is true, but not the point. When defending your system, you should
assume that an attacker can run programs as a local user, as this is usually
the first manner in which someone compromises your scripts.
Mike Bilow <mikebw@colossus.bilow.com> wrote:
> 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.
Not true. See below.
Charles Daminato <chuck@opensrs.org> wrote:
> The best security (including security by obscurity) is ensuring the file
isn't in your document/cgi-bin root for web
> browsers. Par example:
> /home/httpd/html - Document Root
> /home/httpd/cgi-bin - CGI Root
> /home/httpd - Location of OpenSRS.conf
> If anyone can get around that, it wont matter where on your system you put
stuff :)
Here's where I disagree. It _does_ matter where you put the stuff on your
system.
I'd like to present my layout for comment:
For ownership and permissions I'll use owner.group/Octalmod. So
opensrs.www/750 means owned by opensrs, group www, permissions 750.
- Create an opensrs user. Set the home directory (/home/opensrs) to
opensrs.www/750.
- Inside there, creatre a "cgi" directory (root.www/750) and a "live"
directory (opensrs.opensrs/711)
- In the cgi directory, install sbox.
(http://stein.cshl.org/WWW/software/sbox/). I have patched sbox to only run
programs in a particular directory, rather than the default behaviour of
doing this on a ~username basis. It points to /home/opensrs/live/cgi
- in the live directory are all the opensrs directories, cgi, etc, lib,
templates. They are all opensrs.opensrs/700.
Why I believe this works:
A user on the local machine (assuming that they cannot gain additional
privilege ;)) cannot run sbox, as it will only run under the webserver.
The webserver can only run the given CGI scripts as the opensrs user. If
these scripts are safe, only root and opensrs can read the config files.
Obviously the security of this rests in the security of sbox and my patch.
The patch has been submitted to the author of sbox, and I'd be happy to
release it once its had some peer review, so if anyone is willing and able
to review a small chunk of C for security, please mail me off-list.
If I've missed something, please let me know. I'd like to be able to make my
system more secure as well.
-- Grant
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT