On Wed, 29 Mar 2000, David Harris wrote:
>
> Charles Daminato wrote:
> > All your methods are well placed and nicely described. 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 :)
>
> Sadly there hasn't been any actual discussion of the file ownership and
> permissions going on here. I'm betting that 90% of the OpenSRS installations
> out there are open to another user on the system reading your OpenSRS.conf
> file. It's all nice and fine to secure against someone on the web grabbing your
> file, but the real danger is a user on your system. who also has access to the
> restricted ipaddress you registered with OpenSRS, since they are a user on your
> system).
>
> I was talking off-list with one of the security proponents on this list and he
> admitted that any other user on the system could read his OpenSRS.conf file.
> That's out-right scary if you ask me.
>
> The answer to this problem is to (a) run the suexec apache extension or (b) run
> a separate web-server for your private stuff under a different user-id on a
> different port, (c) run a set-uid CGI wrapper like cgi-wrap. I don't think
> setuid is a good answer, it is too tricky and has too many traps.
>
All of these choices require root on the system. If you have root on the
system, the simple solutions are (a) run the webserver as a user, say www,
and chown/chgrp www Opensrs.conf, chmod 600 Opensrs.conf. (b) don't have
untrusted users on your webserver.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT