From owner-freebsd-ports Thu Oct 23 20:37:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA17774 for ports-outgoing; Thu, 23 Oct 1997 20:37:26 -0700 (PDT) (envelope-from owner-freebsd-ports) Received: from wireless.wdc.net (wireless.wdc.net [204.140.136.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA17764 for ; Thu, 23 Oct 1997 20:37:22 -0700 (PDT) (envelope-from bad@uhf.wireless.net) Received: from uhf.wireless.net (uhf.wdc.net [198.147.74.44]) by wireless.wdc.net (8.8.5/8.8.5) with ESMTP id UAA00734; Thu, 23 Oct 1997 20:36:00 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wireless.net (8.8.7/8.8.7) with SMTP id XAA00668; Thu, 23 Oct 1997 23:39:17 -0400 (EDT) Date: Thu, 23 Oct 1997 23:39:16 -0400 (EDT) From: Bernie Doehner To: Marc Slemko cc: "Scot W. Hetzel" , FreeBSD Ports Subject: Re: Apache w/FrontPage Module Port In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I suggest we take this to private email. > Those directories should NEVER EVER EVER (unless you are an uber-guru and > know what you are doing and what the risks are and how to avoid them) be Tend to differ. On one of our secondary apache servers we have it set up this way because the web server runs on the professor's UID, and most of the apache directories to mode 700 so that noone else can log into the machine and look around them directly (they are used for courses and we wanted to control how information in these directories is presented - only in a controled way through apache, and never directly under Unix). He also needed the flexibility of being able to kill and restart the web server (without root password). There is no other way to accomplish this if you run the web server under the default uid of nobody, and root.wheel file permissions. I am in favor of Scott's proposed way of doing this because it allows for special circumstances such as the one above. > owned by the user Apache runs as. Neither should the Apache binary. Good point, but you eliminate much of the security risk by prohibiting any and all cgi (perhaps this should be the default Scott?). Perhaps, also the installer should be warned about making the configuration directories owned by the same user as runs the server? I tend to differ however about the ownership of the binary (as long as you don't set the setuid/setgid bits). The only thing that ownership and mode will affect is who can run the binary. > Neither should the directory logs are in. If you do not heed these > warnings, you loose all guru points and risk a root compromise. Don't know what your thing with these guru points is. I don't see your point about root compromise in the case that web server is run by the same uid as the owner of the logs directory.. Assuming someone can maliciously mangle the logs through apache, at most it would be a user compromise. A bit far fletched, but perhaps possible through the frontpage module (only module I haven't picked apart yet). > Again, these files should not be writable or owned by the user Apache runs > as. Nothing should, with the possible exception of data files that some > CGIs want to manipulate. If security it is that you want, then CGI scripts should also be prohibited. > The frontpage extensions have wanted many things to be true with your > Apache setup; if this is one of them, then don't be silly enough to listen > to Microsoft. >From what I have seen about frontpage clients that certainly seems to be the case.. Bernie