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.
These people who claim to have a "secure installation" and are talking
endlessly about keeping a web user from downloading the file (which is only the
first step towards security!) - if one of these people gives me a user account
on their system I can probably e-mail them their private key and register a
domain or two.
- David Harris
Principal Engineer, DRH Internet Inc.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:22 EDT