You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Rich Bowen <rb...@rcbowen.com> on 2002/09/21 20:16:27 UTC
Security
I have been doing Apache training this week for some folks that are very
concerned about security. We spent about half of Friday doing two
things. First, we attempted to figure out what the absolute minimum set
of modules was that Apache could run with. Second, we tried to figure
out what the minimal file permissions were that we could put on the
Apache directories and still have things work.
With regard to the former, I discovered some things which surprised me
just a little. With regard to the latter, we discovered that the
recommended file permissions in the documentation are much more open
than they need to be.
I'm going to write up some of our observations over the next few days as
I have time, and was hoping to stir up a little interest so that when I
have something, some folks will be willing to take a look at it.
Rich
--
Pilgrim, how you journey on the road you chose
To find out where the winds die and where the stories go
--Pilgrim (Enya - A Day Without Rain)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Astrid Kessler <ke...@kess-net.de>.
> I'm going to write up some of our observations over the next few days as
> I have time, and was hoping to stir up a little interest so that when I
> have something, some folks will be willing to take a look at it.
You'll get a lot of interest ;-)
Maybe I won't be able to tell you exactly, if you are right or wrong. But I
can tell you, if I understand the explanations or miss something.
Kess
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: ssl xml files
Posted by Joshua Slive <jo...@slive.ca>.
Thomas Sjögren wrote:
> I've converted the SSL/TLS documents (attached file).
>
> However, there's a couple of bugs:
> * The content listing tends to be a little to much (ssl_faq.html.env).
>
> * Some links react strange (in Mozilla anyway), take a look at the
> References section in ssl_intro.html.en.
>
> * The boxes in ssl_howto.html.en doesn't look good.
>
> I'll check the code again tomorrow (a couple of things needs to be
> updated and some minor design flaws (except the ones above) will be delt
> with).
At a quick look it seems fine. Yes, some of the structure should be
simplified a little. In addition, the glossary can be tossed. All
those terms are folded into the main glossary.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
ssl xml files
Posted by Thomas Sjögren <th...@northernsecurity.net>.
I've converted the SSL/TLS documents (attached file).
However, there's a couple of bugs:
* The content listing tends to be a little to much (ssl_faq.html.env).
* Some links react strange (in Mozilla anyway), take a look at the
References section in ssl_intro.html.en.
* The boxes in ssl_howto.html.en doesn't look good.
I'll check the code again tomorrow (a couple of things needs to be
updated and some minor design flaws (except the ones above) will be delt
with).
/Thomas
--
thomas@northernsecurity.net | www.northernsecurity.net
thomas@se.linux.org | www.se.linux.org
RE: Security
Posted by Vincent de Lau <vi...@delau.nl>.
> > In general, we have tried to stay away from unix tutorials in the apache
> > docs. We need to document Apache, not the operating system. If we try
> > to be all things to all people, we will wind up with crappy docs.
> >
>
> Sorry, talking about security means always talking about the underlying
> system. I agree with you, that the apache documentation is not the right
> place to teach people using their system. But if we are talking about
> securing the apache, we schould not only mention the minimum rights. Imho
> we should also offer some help, to keep this settings. And umask is a big
> help. We may add a sentence like 'For further information read the
> corresponding man pages', or something else.
>
> I've often realized, that the problem isn't really reading the
> documentation at a special topic, but more knowing, there is something,
> which will help. Give the people a hint.
First describing WHAT you are doing and then describing how you are doing it
(on one or more platforms) seems a good idea. This helps people 'porting'
docs to other platforms as well. For instance:
section 1: securing log files
- we want to prevent other users then the server user and administrator from
reading the logs
section 1.1: Unix settings
- change owner
- change permissions
- set umask
section 1.2: Win32 settings
- clear the log directory ACL
- give write permissions to Administrators
- give write acces to "creater-owner"
On the other hand you might have sections that are equal for all platforms
(like modules).
Vincent de Lau
vincent@delau.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Astrid Kessler <ke...@kess-net.de>.
>> What I think you would want is to change the default umask of the users
>> in question
>> 'umask 022' is pretty typical, so probably want something less public.
>
> In general, we have tried to stay away from unix tutorials in the apache
> docs. We need to document Apache, not the operating system. If we try
> to be all things to all people, we will wind up with crappy docs.
>
Sorry, talking about security means always talking about the underlying
system. I agree with you, that the apache documentation is not the right
place to teach people using their system. But if we are talking about
securing the apache, we schould not only mention the minimum rights. Imho
we should also offer some help, to keep this settings. And umask is a big
help. We may add a sentence like 'For further information read the
corresponding man pages', or something else.
I've often realized, that the problem isn't really reading the
documentation at a special topic, but more knowing, there is something,
which will help. Give the people a hint.
Kess
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Joshua Slive <jo...@slive.ca>.
Philip M. Gollucci wrote:
> * Note that new files created may not have the right permissions on them
>
> * May need to correct this with a periodic cron'ed chown/chmod.
>
> * Is there an argument to chmod to make new files have the right
> attributes?
The "sticky bit".
>
>
> What I think you would want is to change the default umask of the users
> in question
> 'umask 022' is pretty typical, so probably want something less public.
In general, we have tried to stay away from unix tutorials in the apache
docs. We need to document Apache, not the operating system. If we try
to be all things to all people, we will wind up with crappy docs.
Now, if we could find a good general unix-permissions tutorial on the
web, then there would be nothing wrong with providing a strategic link.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by "Philip M. Gollucci" <ph...@p6m7g8.com>.
* Note that new files created may not have the right permissions on them
* May need to correct this with a periodic cron'ed chown/chmod.
* Is there an argument to chmod to make new files have the right attributes?
What I think you would want is to change the default umask of the users
in question
'umask 022' is pretty typical, so probably want something less public.
Rich Bowen wrote:
>On Sat, 21 Sep 2002, Rich Bowen wrote:
>
>
>
>>On Sat, 21 Sep 2002, Rich Bowen wrote:
>>
>>
>>
>>>I'm going to write up some of our observations over the next few days as
>>>I have time, and was hoping to stir up a little interest so that when I
>>>have something, some folks will be willing to take a look at it.
>>>
>>>
>>OK, please forgive the format. This is a "perlpoint" presentation that I
>>put together for the class that I was teaching, and modified based on
>>our findings.
>>
>>One thing that I'd like to ask about is the deal with mod_mime. If I
>>have a web site consisting *only* of DefaultType documents (say, if I
>>set DefaultType to text/html), then why can't I run Apache without
>>mod_mime?
>>
>>When I tried (ie, ran Apache with only mod_dir and mod_log_config) and
>>went to http://server/ I would get a 404 page, and the error log would
>>say "file /usr/local/apache/htdocs/ not found"
>>
>>Anyways, here's our findings. Comments welcome. I'd like to incorporate
>>these into the security doc, which is a little elderly and somewhat
>>sparse in these particular areas.
>>
>>
>
>Crap. Forgot to attach it. Bah.
>
>
>=Apache security
>
>* Remove modules you're not using
>
>* Set file permissions right
>
>=Modules you're not using
>
>* What is the minimal list of modules you can get away with?
>
>* Why do you need them?
>
>=Module list
>
>* The minimal module list appears to be:
>
> mod_dir
> mod_mime
> mod_log_config (optional, but recommended)
>
>=mod_dir
>
>* Provides DirectoryIndex directive
>
>* People will want to look at http://servername/ and get something useful
>
>=mod_mime
>
>* Necessary if you are serving any files other than DefaultType ones
>
>* For some reason, even DefaultType won't work without mod_mime
>
>=mod_log_config
>
>* You could get away with not running it
>
>* Log files are a good thing if you are going for security
>
>=File permissions
>
>* Recommended file permissions in the docs are crap
>
>* Can get much tighter than that
>
>* Docs should list the I<minimum>, and let you go from there
>
>* Note that directories have to have x in order to cd into them
>
>* It is assumed that C<User> is set to C<www> and that C<Group> is set to C<www>
>
>=ServerRoot
>
>* ServerRoot itself should be root.www
>
>* Should be read and execute for root and www
>
> cd /usr/local/apache
> chown root.www .
> chmod 550 .
>
>=bin
>
>* The C<bin> directory itself should be C<root.root> and 500
>
>* Files should be 100, except for the script files, which should be 500
>
>* C<suexec> is suid, so should be 4100
>
> chown root.root bin
> chmod 500 bin
> cd bin
> chmod 100 *
> chmod 500 apachectl dbmmanage apxs
> chmod 4100 suexec
>
>=conf
>
>* conf/ is only ever read by root
>
>* Directory should be root.root
>
>* Directory should be 500
>
>* and files should be 400
>
> chown -R root.root conf
> chmod 500 conf
> cd conf
> chmod 400 *
>
>* Note that if you have subdirectories, they should have similar permissions
>
>=cgi-bin and htdocs
>
>* This also applies to other "content" directories
>
>* Two scenarios we consider
>
>* 1) A single content provider
>
>* 2) 2 or more content providers
>
>* Here, "provider" means the person that is producing and maintaining the content
>
>* Other content directories, like C<icons>, should be treated similarly
>
>=Content with one provider
>
>* A single user creates and maintains content. Assume this user has a username C<content>
>
>* Directory (htdocs or cgi-bin, for example) should be owned by C<content.www>
>
>* The directory, and any subdirectories, should be 750
>
>* The files should all be 640
>
> chown -R content.www htdocs
> chmod 750 htdocs
> cd htdocs
> chmod 640 *
>
>* Repeat for subdirectories as needed
>
>=Content with more than one provider
>
>* More than one user provides content
>
>* Create a group called C<content> and put all these users in that group
>
>* Directory should be owned by C<root.content>
>
>* Directory, and any subdirectories, should be 574
>
>* Files should be 664
>
> chown -R root.content htdocs
> chmod 574 htdocs
> cd htdocs
> chmod 664 *
>
>* Repeat for subdirectories as needed
>
>=Multiple providers, cont'd
>
>* Note that new files created may not have the right permissions on them
>
>* May need to correct this with a periodic cron'ed chown/chmod.
>
>* Is there an argument to chmod to make new files have the right attributes?
>
>=include
>
>* Owned by root.root
>
>* Readable only by root
>
> chown -R root.root include
> chmod 500 include
> cd include
> chmod 400 *
>
>=libexec
>
>* Only needed if you have modules built as shared objects
>
>* If you do, then it should be readable only by root
>
> chown -R root.root libexec
> chmod 500 libexec
> cd libexec
> chmod 400 *
>
>=logs
>
>* Logs directory has some caveats
>
>* Standard log files are written as root (C<access_log> and C<error_log>)
>
>* Some other modules log as C<www.root>
>
>* So, here's the recommendation:
>
> chown root.www logs
> chmod 770 logs
>
>* Log files are created at startup, so there's no need to modify permissions inside the directory, as permissions will change next time you restart.
>
>* Can modify C<mod_log_config.c> to create file without C<group> and C<other> readability if desired.
>
> - static mode_t xfer_mode = (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
> + static mode_t xfer_mode = (S_IRUSR | S_IWUSR);
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Thomas Sjögren <th...@northernsecurity.net>.
On Sunday 22 September 2002 09:03, Joshua Slive wrote:
> Your permissions keep ordinary users entirely out of the Apache
> directories.
<--- snip --->
> Now, it could be argued that under some circumstances, an
> adminstrator would not want ordinary users to do those things.
Correct, but this could be fixed by creating a user only for apache
(user apache, group apache) that has the permissions to running
log-analysis programs and reading the error log among other things.
This would eliminate the use of root/administrator.
/Thomas
--
thomas@northernsecurity.net | www.northernsecurity.net
thomas@se.linux.org | www.se.linux.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sun, 22 Sep 2002, Joshua Slive wrote:
> Rich Bowen wrote:
>
> > OK, I'm confused. What here would you have to do as root that should not
> > be that way?
>
> I'm not anything near a security expert, but ...
>
> Your permissions keep ordinary users entirely out of the Apache
> directories. This prevents ordinary users from doing, among other things:
>
> - Running log-analysis programs
> - Reading the error log
> - Running htpasswd/htdigest/ab and other support programs
> - Reading the httpd.conf to check how the server is configured
Yes, that was the goal.
> Now, it could be argued that under some circumstances, an adminstrator
> would not want ordinary users to do those things. For example, the
> error log could contain sensitive error dumps from cgi scripts. Or the
> httpd.conf could contain database passwords for php scripts. But in
> general, a properly configured system should not really need to restrict
> these things.
The idea was to lock things down as tightly as possible, and then use
that as a baseline for relaxing things based on needs that arose. Keep
in mind that the folks in question were security experts, whose entire
job is to be paranoid.
> The philosophy of the existing recommendations is to restrict write
> access tightly, but to allow pretty-much unlimited read access. I don't
> see this as a bad idea. Perhaps the docs should note that more
> restrictive read-permissions are possible, but I don't think they need
> to be "recommended".
Granted. The phrasing could be be better than what I have suggested.
> As far as the log directory, you've already discovered that it works in
> general with the recommended no-write-permissions-to-non-root. I
> believe there may be some things (like the scriptlog) that don't work
> that way. For these logs, it is necessary to create the file in advance
> and chown it to www.
>
> Regarding the requirement for mod_mime, I do belive that is some kind of
> a bug. I recall some discussion of this a long time ago on new-httpd,
> but I can't remember the conclusions. I'd guess the only way to figure
> it out would be to walk it with a debugger.
I'll paw through the archives and see what I can come up with.
> So, in conclusion, I like the idea of adding a discussion of how to
> remove features (modules) that aren't needed, and perhaps a little bit
> more discussion of file-permissions. But I don't really see any need to
> change the recommended file-permissions.
If that is the consensus, I'll drop it. I think that the document could
stand to be expanded in a number of areas, and that a broader discussion
of file permissions would be good here. I think that I agree re actually
recommending that everyone change their file permissions, in general.
Perhaps merely discussing them more will get people thinking in areas
that they would not otherwise.
Re modules, I find a huge number of people on IRC that have modules
installed that they don't even know what they do, let alone actually
need them. I had thought before of what would be the minimal module
load, but had never actually attempted to do one. I found it an
interesting and informative experiment. I also discovered the
--enable-module=none flag, which is not documented anywhere that I could
find.
--
Who can say where the road goes
Where the day flows
Only time
--Pilgrim (Enya - A Day Without Rain)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Joshua Slive <jo...@slive.ca>.
Rich Bowen wrote:
> OK, I'm confused. What here would you have to do as root that should not
> be that way?
I'm not anything near a security expert, but ...
Your permissions keep ordinary users entirely out of the Apache
directories. This prevents ordinary users from doing, among other things:
- Running log-analysis programs
- Reading the error log
- Running htpasswd/htdigest/ab and other support programs
- Reading the httpd.conf to check how the server is configured
Now, it could be argued that under some circumstances, an adminstrator
would not want ordinary users to do those things. For example, the
error log could contain sensitive error dumps from cgi scripts. Or the
httpd.conf could contain database passwords for php scripts. But in
general, a properly configured system should not really need to restrict
these things.
The philosophy of the existing recommendations is to restrict write
access tightly, but to allow pretty-much unlimited read access. I don't
see this as a bad idea. Perhaps the docs should note that more
restrictive read-permissions are possible, but I don't think they need
to be "recommended".
As far as the log directory, you've already discovered that it works in
general with the recommended no-write-permissions-to-non-root. I
believe there may be some things (like the scriptlog) that don't work
that way. For these logs, it is necessary to create the file in advance
and chown it to www.
Regarding the requirement for mod_mime, I do belive that is some kind of
a bug. I recall some discussion of this a long time ago on new-httpd,
but I can't remember the conclusions. I'd guess the only way to figure
it out would be to walk it with a debugger.
So, in conclusion, I like the idea of adding a discussion of how to
remove features (modules) that aren't needed, and perhaps a little bit
more discussion of file-permissions. But I don't really see any need to
change the recommended file-permissions.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sat, 21 Sep 2002, Rich Bowen wrote:
> > > * So, here's the recommendation:
> > >
> > > chown root.www logs
> > > chmod 770 logs
> >
> > This goes explicitly against what is documented in the current docs
> > and allow anyone who compromises the "www" group to gain root access
> > to the system.
>
> Can you elaborate as to how that would happen?
>
> The current docs say that the directory should be 755, which would
> prevent ssl from logging. Or so I would have thought. Need to experiment
> with that, I guess.
OK, I stand corrected. Making logs root.root and 750, ssl still creates
its log files quite happily, and they are owned by nobody.root. How it
is doing this, I'm not clear, but I suppose I should go paw through the
source code for that one.
The concern with making the log directory readable, by my paranoid
students, was that a user who gained acces to the server as an
unprivileged user could watch the log files to see the effects of things
that they were trying. Yes, some of these things seem a little overly
paranoid, but that was sort of the point - minimal permission
recommendations, and you can go from there.
--
Oh I have slipped the surly bonds of earth
And danced the sky on laughter-silvered wings
--High Flight (John Gillespie Magee)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 21 Sep 2002, Rich Bowen wrote:
> On Sat, 21 Sep 2002, Marc Slemko wrote:
>
> > On Sat, 21 Sep 2002, Rich Bowen wrote:
> >
> > >
> > > =Apache security
> >
> > Two comments:
> >
> > 1. a lot of silly and futile restrictions here that don't do anything
> > to improve security and only serve to make people do things as root
> > more than they should have to.
>
> OK, I'm confused. What here would you have to do as root that should not
> be that way?
Almost anything involving the server you are now requiring that
the user be root to do... running htpasswd, compiling modules that
use the include files, checking the logs, verifying how things are
setup in the conf file... the list goes on and on. Restricting
permissions so everyone needs root to do anything and anyone who
has root has to be root all the time is unwise.
While some of that (eg. read access to the logs) are legitimate
for some shared systems where you don't want people doing that
(note that doesn't mean it would be a reasonable default), others
(eg. access to run htpasswd) are completely futile and don't improve
security one bit.
>
> > 2. Your recommend permissions for the logs directory have a huge
> > problem:
> >
> > > * Logs directory has some caveats
> > >
> > > * Standard log files are written as root (C<access_log> and C<error_log>)
> > >
> > > * Some other modules log as C<www.root>
> > >
> > > * So, here's the recommendation:
> > >
> > > chown root.www logs
> > > chmod 770 logs
> >
> > This goes explicitly against what is documented in the current docs
> > and allow anyone who compromises the "www" group to gain root access
> > to the system.
>
> Can you elaborate as to how that would happen?
>
The logs are opened as root.
Symlinks are followed.
It is trivial to make Apache log a line containing user supplied input
since, umh, that is what logging is.
If you can append arbitrary input to any file on the system as root, there
are a lot of ways to compromise the system.
> The current docs say that the directory should be 755, which would
> prevent ssl from logging. Or so I would have thought. Need to experiment
> with that, I guess.
>
> > Do not give the user or group the server runs as
> > write permissions to the log directory if the server is started as
> > root.
>
> That's the way that it is now. SSL logs as the web server user, as does
> mod_throttle, and mod_gzip. If you don't give that user access to write
> to the log directory, these modules can't log.
As I already said directly below, if you have random modules that
insist for some reason on writing as the user the webserver runs
as (doing so is itself a security risk) then you need to precreate
those files with the proper permissions.
This isn't some random "I think things should be this way" statement,
it is a simple and documented fact that anyone who you give write
access to the logs directory can compromise the user that starts Apache,
in this case root. Whatever requirements random modules have doesn't
change this, if they are broken they are broken.
>
> > If you have some random module that wants to write a logfile as the
> > user the webserver runs as, either put it in a different directory or
> > precreate the file with permissions that let the module do so.
>
> Well, I would hardly call mod_ssl "some random module". ;-) What
> recommendations do you make for that?
In Apache 2.0 mod_ssl doesn't seem to have its own logfile, in
Apache 1.3 it seems to open it as the user that apache is started by
(ie. root, in this case), so I'm not sure where the problem is here.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sat, 21 Sep 2002, Marc Slemko wrote:
> On Sat, 21 Sep 2002, Rich Bowen wrote:
>
> >
> > =Apache security
>
> Two comments:
>
> 1. a lot of silly and futile restrictions here that don't do anything
> to improve security and only serve to make people do things as root
> more than they should have to.
OK, I'm confused. What here would you have to do as root that should not
be that way?
> 2. Your recommend permissions for the logs directory have a huge
> problem:
>
> > * Logs directory has some caveats
> >
> > * Standard log files are written as root (C<access_log> and C<error_log>)
> >
> > * Some other modules log as C<www.root>
> >
> > * So, here's the recommendation:
> >
> > chown root.www logs
> > chmod 770 logs
>
> This goes explicitly against what is documented in the current docs
> and allow anyone who compromises the "www" group to gain root access
> to the system.
Can you elaborate as to how that would happen?
The current docs say that the directory should be 755, which would
prevent ssl from logging. Or so I would have thought. Need to experiment
with that, I guess.
> Do not give the user or group the server runs as
> write permissions to the log directory if the server is started as
> root.
That's the way that it is now. SSL logs as the web server user, as does
mod_throttle, and mod_gzip. If you don't give that user access to write
to the log directory, these modules can't log.
> If you have some random module that wants to write a logfile as the
> user the webserver runs as, either put it in a different directory or
> precreate the file with permissions that let the module do so.
Well, I would hardly call mod_ssl "some random module". ;-) What
recommendations do you make for that?
--
Rich Bowen - rbowen@rcbowen.com
Author - Apache Administrator's Guide
http://www.ApacheAdmin.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 21 Sep 2002, Rich Bowen wrote:
>
> =Apache security
Two comments:
1. a lot of silly and futile restrictions here that don't do anything
to improve security and only serve to make people do things as root
more than they should have to.
2. Your recommend permissions for the logs directory have a huge
problem:
> * Logs directory has some caveats
>
> * Standard log files are written as root (C<access_log> and C<error_log>)
>
> * Some other modules log as C<www.root>
>
> * So, here's the recommendation:
>
> chown root.www logs
> chmod 770 logs
This goes explicitly against what is documented in the current docs
and allow anyone who compromises the "www" group to gain root access
to the system. Do not give the user or group the server runs as
write permissions to the log directory if the server is started as
root.
If you have some random module that wants to write a logfile as the
user the webserver runs as, either put it in a different directory or
precreate the file with permissions that let the module do so.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sat, 21 Sep 2002, Rich Bowen wrote:
> On Sat, 21 Sep 2002, Rich Bowen wrote:
>
> > I'm going to write up some of our observations over the next few days as
> > I have time, and was hoping to stir up a little interest so that when I
> > have something, some folks will be willing to take a look at it.
>
> OK, please forgive the format. This is a "perlpoint" presentation that I
> put together for the class that I was teaching, and modified based on
> our findings.
>
> One thing that I'd like to ask about is the deal with mod_mime. If I
> have a web site consisting *only* of DefaultType documents (say, if I
> set DefaultType to text/html), then why can't I run Apache without
> mod_mime?
>
> When I tried (ie, ran Apache with only mod_dir and mod_log_config) and
> went to http://server/ I would get a 404 page, and the error log would
> say "file /usr/local/apache/htdocs/ not found"
>
> Anyways, here's our findings. Comments welcome. I'd like to incorporate
> these into the security doc, which is a little elderly and somewhat
> sparse in these particular areas.
Crap. Forgot to attach it. Bah.
=Apache security
* Remove modules you're not using
* Set file permissions right
=Modules you're not using
* What is the minimal list of modules you can get away with?
* Why do you need them?
=Module list
* The minimal module list appears to be:
mod_dir
mod_mime
mod_log_config (optional, but recommended)
=mod_dir
* Provides DirectoryIndex directive
* People will want to look at http://servername/ and get something useful
=mod_mime
* Necessary if you are serving any files other than DefaultType ones
* For some reason, even DefaultType won't work without mod_mime
=mod_log_config
* You could get away with not running it
* Log files are a good thing if you are going for security
=File permissions
* Recommended file permissions in the docs are crap
* Can get much tighter than that
* Docs should list the I<minimum>, and let you go from there
* Note that directories have to have x in order to cd into them
* It is assumed that C<User> is set to C<www> and that C<Group> is set to C<www>
=ServerRoot
* ServerRoot itself should be root.www
* Should be read and execute for root and www
cd /usr/local/apache
chown root.www .
chmod 550 .
=bin
* The C<bin> directory itself should be C<root.root> and 500
* Files should be 100, except for the script files, which should be 500
* C<suexec> is suid, so should be 4100
chown root.root bin
chmod 500 bin
cd bin
chmod 100 *
chmod 500 apachectl dbmmanage apxs
chmod 4100 suexec
=conf
* conf/ is only ever read by root
* Directory should be root.root
* Directory should be 500
* and files should be 400
chown -R root.root conf
chmod 500 conf
cd conf
chmod 400 *
* Note that if you have subdirectories, they should have similar permissions
=cgi-bin and htdocs
* This also applies to other "content" directories
* Two scenarios we consider
* 1) A single content provider
* 2) 2 or more content providers
* Here, "provider" means the person that is producing and maintaining the content
* Other content directories, like C<icons>, should be treated similarly
=Content with one provider
* A single user creates and maintains content. Assume this user has a username C<content>
* Directory (htdocs or cgi-bin, for example) should be owned by C<content.www>
* The directory, and any subdirectories, should be 750
* The files should all be 640
chown -R content.www htdocs
chmod 750 htdocs
cd htdocs
chmod 640 *
* Repeat for subdirectories as needed
=Content with more than one provider
* More than one user provides content
* Create a group called C<content> and put all these users in that group
* Directory should be owned by C<root.content>
* Directory, and any subdirectories, should be 574
* Files should be 664
chown -R root.content htdocs
chmod 574 htdocs
cd htdocs
chmod 664 *
* Repeat for subdirectories as needed
=Multiple providers, cont'd
* Note that new files created may not have the right permissions on them
* May need to correct this with a periodic cron'ed chown/chmod.
* Is there an argument to chmod to make new files have the right attributes?
=include
* Owned by root.root
* Readable only by root
chown -R root.root include
chmod 500 include
cd include
chmod 400 *
=libexec
* Only needed if you have modules built as shared objects
* If you do, then it should be readable only by root
chown -R root.root libexec
chmod 500 libexec
cd libexec
chmod 400 *
=logs
* Logs directory has some caveats
* Standard log files are written as root (C<access_log> and C<error_log>)
* Some other modules log as C<www.root>
* So, here's the recommendation:
chown root.www logs
chmod 770 logs
* Log files are created at startup, so there's no need to modify permissions inside the directory, as permissions will change next time you restart.
* Can modify C<mod_log_config.c> to create file without C<group> and C<other> readability if desired.
- static mode_t xfer_mode = (S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
+ static mode_t xfer_mode = (S_IRUSR | S_IWUSR);
--
Rich Bowen - rbowen@rcbowen.com
Author - Apache Administrator's Guide
http://www.ApacheAdmin.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Security
Posted by Rich Bowen <rb...@rcbowen.com>.
On Sat, 21 Sep 2002, Rich Bowen wrote:
> I'm going to write up some of our observations over the next few days as
> I have time, and was hoping to stir up a little interest so that when I
> have something, some folks will be willing to take a look at it.
OK, please forgive the format. This is a "perlpoint" presentation that I
put together for the class that I was teaching, and modified based on
our findings.
One thing that I'd like to ask about is the deal with mod_mime. If I
have a web site consisting *only* of DefaultType documents (say, if I
set DefaultType to text/html), then why can't I run Apache without
mod_mime?
When I tried (ie, ran Apache with only mod_dir and mod_log_config) and
went to http://server/ I would get a 404 page, and the error log would
say "file /usr/local/apache/htdocs/ not found"
Anyways, here's our findings. Comments welcome. I'd like to incorporate
these into the security doc, which is a little elderly and somewhat
sparse in these particular areas.
--
Rich Bowen - rbowen@rcbowen.com
As we trace our own few circles around the sun
We get it backwards and our seven years go by like one
Dog Years (Rush - Test for Echo - 1999)
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org