Date: Thu, 23 Oct 1997 22:13:31 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: Bernie Doehner <bad@uhf.wireless.net> Cc: "Scot W. Hetzel" <hetzels@aol.com>, FreeBSD Ports <ports@FreeBSD.ORG> Subject: Re: Apache w/FrontPage Module Port Message-ID: <Pine.BSF.3.95.971023215007.11617H-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.96.971023230917.579C-100000@uhf.wireless.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 23 Oct 1997, Bernie Doehner wrote:
> I suggest we take this to private email.
I don't really want to do that right now, because you raise misleading
points that need clarification. If you wish to in the future, feel free.
>
> > 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.
That is different; it is not running on port 80 presumably and presumable
it is very tightly controlled so only the one user can place make content
available on it. In the vast majority of cases, Apache is started as root
because it does need to bind to port 80.
I still do not recommend doing things as in the above situation because it
allows any holes to compromise the (presumably) important professor's
account. Make things group readable and setup a seperate group to avoid
this risk. Allowing people to start and stop the server can be done with
something like sudo.
>
> I am in favor of Scott's proposed way of doing this because it allows for
> special circumstances such as the one above.
It is not acceptable for the vast majority of sites. Unless I
misunderstand what is being suggested, I would strongly oppose such a port
ever being included in the FreeBSD ports collection and suspect I would be
well supported in this view. Nothing prevents people from setting up
their own server for special circumstances. Defaults must not be made
insecure because of it.
> > 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?
Install script: "hey, I am going to do this but it is a stupid idea.
should I proceed?"
User: "ermmm... I don't have much choice, do I? I don't understand.
Better let it do what it wants, after all the people who made this must
know what they are doing."
That isn't really an option. There is no need. It is not, in the general
case, secure. Prohibiting all CGI is impossible if you are trying to use
MS's FrontPage modifications because the very basis of them is that you
allow the execution of CGIs. CGIs that you don't have the source for.
CGIs that very likely have security holes in. In any case, not only is
prohibiting user CGIs not an option for many, many don't know how to do it
correctly even if they wanted to. Even if they do, it does not solve the
problems. Setup properly, a hole in Apache does not compromise root.
That is the way it should be. You are foolish if you trust the Apache
code (or any other webserver that I have examined) with root; it is far
too large and has far too much legacy code in.
>
> 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.
No. Try it some day. If you own it, you can modify it unless you take
special care like setting it immutable. In the typical setup running on
port 80, that means you can modify a binary run by root.
>
> > 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
My thing with guru points is that some people have been through all these
details before and know the risks and why not to do certain things.
Warnings scattered through the Apache documentation and that I have posted
are not senseless nonsense. They have a very firm basis in reality; I am
not trying demean you or be an arrogant bastard but the fact is that I
have been through these issues, I am very familiar with the Apache source,
and I know many of the consequences of the things you are suggesting.
They are not good and pose unacceptable risks, even if you don't
understand them.
> 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).
No. It gives you very easy root access. The Apache docs explicitly warn
about this for good reason. Hint: what user opens the Apache log files?
What are symbolic links on Unix? Put those two together and you get the
answer. If you really want details, I'm sure you can find reference (try
Dejanews) to a post I made on comp.infosystems.www.servers.unix a number
of months ago that explained all the details.
There are many reasons to not have things owned or writable by the user
Apache runs as.
>
> > 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.
There is a large difference between allowing users to write stupid CGI
scripts and setting your server up so anyone can get almost instant root.
The former is a local policy decision based on what risks are acceptable
to you. The latter is an unacceptable thing to do, especially for a
distributed port.
--
Marc Slemko | Apache team member
marcs@znep.com | marc@apache.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.971023215007.11617H-100000>