[Matthew J. Probst] | | malicious users? If the admin server is a striped down httpd | running as root, with access.conf that limits access to only | specific machines AND we have the think password protected, I dont | think that will leave much room for hackers. local users won't have | any more rights than remote users.
I am not trying to flame you or be impolite, but it's funny that someone would use the phrase "I dont think that will leave much room for hackers" in a mail to me today, when I've spent most of my working day chasing a merry band of hackers around a university site and try to find out how extensive the damages are. of course, they will never be caught and their identity is safe because the law and an uncooperative ISP is not on our side. also the university don't really wish to solve the problem; they just wish to remove the symptoms, or at least make them less visible. their security is basically based on the idea "they will never bother to find out what..." or "they won't guess...". first off, running httpd as root is not a good idea. it is bad enough that it has to be started as root in order to bind() to a low port number and then switch to a different userid. it should run as a different user than root AND a different user than the httpd it is supposed to configure. if it runs as root it's just a question of time before someone severely compromises the machine. (I know, I have cleaned up after several disasters of that flavor.) the configuration server should under no circumstances run as root. the tasks you need to perform as root should be contained within separate programs suid that do _nothing_ else than, start, stop, or restart the server. they should be as simple as possible and as paranoid as possible. although I have great confidence in those who have written the Apache httpd code, httpd is simply too much code and it is close to impossible to be even remotely sure there is nothing that can be exploited within it. [snip] | I have complete faith that a 1 process striped down apache httpd | will not crash until the whole machine crashes. This is something | we can rely on. Then, by using CGI Perl or C (which is easily | ported to NT) the config files could be modified and the server | could be restarted. and if it does crash that shouldn't really be a problem because you could wrap it into a script that restarts the config server. | Some people were discussing the idea of throwing API into apache to | allow us to control the server from inside out.. well... this might | be nice but for now I think its overkill. and hey... if the main | httpd is crashed for some reason all the internal APIs in the world | wont help you anyway. It would be wiser just to restart the server | anyway. right now I am under the impression that we are still brainstorming, trying to come up with ideas of what might be a good solution or a good set of solutions. I don't think we should dismiss every idea that doesn't "fit the bill". on one hand we have my wishes, which are a tad baroque, and on the other hand we have something that can be crufted together in a couple of days. let's hear some more ideas first before we decide on anything. | I also agree with the idea of developing somthing for the apache 1.x | config file format then proceeding from there.. it should be | trivial to change the code to understand the 2.x directive format. I do agree on that, but I think that we need to see a bit beyond just generating configuration files. (I know I might sound paranoid, but after having followed a bunch of hackers around and tested their tools it is pretty obvious that most sites are just accidents waiting to happen) -Bj�rn -- Bj�rn Borud <[EMAIL PROTECTED]> | "The Net interprets censorship <URL:http://www.pvv.unit.no/~borud/> | as damage and routes around it." UNIX person, one of "them" | - John Gilmore
