Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of bob@proulx.com designates
 216.17.153.58 as permitted sender)
Date: Thu, 8 Aug 2013 16:33:56 -0600
From: Bob Proulx <bob@proulx.com>
To: users@httpd.apache.org
Message-ID: <20130808223356.GE24879@hysteria.proulx.com>
References: <1375903871.8152.7232403.1054DC75@webmail.messagingengine.com>
 <CAGBAQ47mHW8VNNbY7ozvBZ7pMj6UqNzEd7=PRmYDmtDpjn+A3g@mail.gmail.com>
 <93AD26CE-52D5-4C18-95F6-3021AFB0B1EC@fastmail.fm>
 <201308081320.53761.john.iliffe@iliffe.ca>
 <D362A337-5D55-4713-9AD6-5E77C31E63E8@fastmail.fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D362A337-5D55-4713-9AD6-5E77C31E63E8@fastmail.fm>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [users@httpd] Changing the User Which Runs Apache

Noah Duffy wrote:
> WordPress may be a bad example, but here's what I'm trying to accomplish:

If nothing else it is extremely popular.

> When installing, there are just a few files and directories which
> contain the pages and PHP. Upon first visit, it has you enter your
> admin password and then it generates a config file. That file cannot
> be generated if Apache (or the user) does not have write permissions
> to the web directory.

A typical situation in the PHP community is to have the php scripts
have full permissive access to the files on disk in the document root
tree.  This is a situation that makes old-school Unix hacks like
myself shudder uncontrollably.  Because it enables endless web site
security vulnerabilities such as are often seen in the php community.
Because any crack into the php code from the web enables full write
access to the filesystem.  And so we have a long history of php cracks
leading people to think that php itself is insecure.  But it isn't php
as such.  It is the strategy of allowing full access that is part of
the php community.

The reason is that it enables adminstration of the site from the web.
This makes it simpler for people to administer sites when they don't
know anything about files, ownership, groups, permissions, processes
and so forth.  All of that is hidden away behind the web browser
interface.  Opening up the file system gains easy remote adminstration
through the web site itself.  Of course that same access enables a
large surface area for security attacks against it too.

Previously you wrote:
> I'm running Ubuntu Server 12.04 and just checked the default
> permissions on /var/www and the owner is actually root. Apache is run
> as www-data, however.

Right.  That is the normal default security settings.  The files are
owned by root because that is the normal system owner for system
files.  Apache runs as www-data specifically so that it does NOT have
write access to those files.  It can read them.  It cannot write them.
If an attack cracks through it will be as the www-data user and by
default there is no interesting writable directory for the attacker to
write.  (It could write into /tmp.  Not interesting.)  This use of the
www-data user is one useful layer of security.  The files on disk
cannot be changed.

> Now that I'd like to host a very small site on a home server, I'm
> trying to take security seriously.

And so when you ask a question such as this it creates a conflict.
You wanting security and the lack of it from the package you want to
install.

If you want to take security seriously then you want to create layers
of security.  By default the apache http daemon on most distros such
as the previously mentioned Debian runs as a non-root, non-privileged
www-data user.  That is the secure setting.  It can read files.  It
has no permission to write files.  This is also very typical for php
too.  And normally instead of writing files on disk the php code will
write data into a database instead of the file system.  (Removing file
permission issues and writing to a database is a primary reason people
like using databases for even trivial things.  Because it removes the
file ownership and permission issue that many non-technical people
don't understand.)

So what do you do about php packages that want full file system access
and won't work without it?  That is a good question.  If you just want
simple, "do it", then you give it full access.  Close your eyes and
ignore the issues.  And then later do clean-ups of your site routinely
when it is cracked.

Several times now I have had people think that Google has flagged
their site as malware when it wasn't Google at all but it was their
anti-virus safe web browsing plugin that flagged it on the Google
search results page.  Their AV has flagged the site and when I look I
plainly see it.  The most common crack I see uses Javascript to make
itself invisible to most browsers.  (To see those cracked sites turn
off Javascript and the link spam becomes visible.  In the last three
months I have twice seen link spam cracks.  When I reported one 5K run
community site I got a thank you and that explains why when they
posted to Facebook that FB showed them a pharmaceutical site instead
because it was the first link hidden on the page.)  The more popular
the php framework the more of a target it becomes to automated
attacks.

Therefore if you are really concerned about security then you simply
cannot give the web application the ability to write to all of the
files on the disk.  (If it only needed a specific "tmp" dir or some
other specific directory then I would consider that okay.)  Which
means that you will have to go against the php developer that wants to
work that way and figure it out and do it yourself.  It is harder
because those slackers aren't helping you because they don't care
about your security.  If you do care then you will have to work harder
to make up the difference.

The reason the answers being provided have been recommending to use a
non-privileged user is because you are asking in the Apache mailing
list not the PHP mailing list.  So the Apache folks here are giving
you straight answers recommending normal security procedures as a
general statement without talking about specific (arguably bad) php
practices.

> Even if I temporarily change the permissions, uploading posts would
> have to be done over SFTP instead of through the website. This
> doesn't bother me, but it does make it take just a few more steps.

If you can do this as an initial setup and change it for production
then I don't see a security problem.  Just make sure that your web
site isn't accessible to anyone else during the setup time period.
Get it set up.  Then fix the permissions appropriately.  Then make it
accessible.  That should be okay.

Doing it this way means that you might have to do more work.  You
might run across some feature that does not work as designed.  You
will need to debug that and own the problem and fix it yourself.  That
might be to open up permissions on a tmp directory.  It might mean
something different.  Also when upgrading you might have to take your
site offline to others, open up permissions, upgrade using the php
framework, then lock things down again.  Being out of the mainstream
you will have to be confident enough to support yourself.  It can be
done.

> Currently, I created a new directory under /srv for the
> files to be hosted and made the owner and group www-data. I then
> added myself as a user to the www-data group so files could make
> changes and the site could create whatever files it needed to.

If you want to run as the php developer wants you to run then that is
the typical php thing to do.

You might want to run AIDE (anti intrusion detection) on those files.
If they ever change when you don't expect them to change then you know
you need to jump on it and clean up after a crack.

> Would that not be safe? I hope no one feels like I'm beating this
> subject, I'm just trying to get a better understanding. :)

Safe?  No.  It is not safe.  All you need to do to prove this is to
look at all of the web cracks that have happened just in the last
year.

Is it done anyway?  Grr...  Yes.  Apparently many people running php
cms sites run this way.  Because I have seen a lot of cracked sites
this year using attacks against the file system so you will be in good
company.

But if that is what you want then that is okay.  It won't hurt me any.
It is unlikely that they will be able to punch through and attack the
underlying host system.  It is probably just your web site presence
that is at risk.  Like the 5K run site that posted to FB and FB
displayed the pharm link spam instead of what they were expecting.

If you don't need a high level of security then maybe a low bar is
good enough.  (shrug.)  Maybe running a routine check daily against
the site and files and reacting to attacks is good enough.  It is a
judgement issue.  You will need to decide for yourself.

> So, should I not give write permissions to any other user other than
> myself?

Is there anyone else who you will be sharing administration of these
files with on the machine?  If so then add them to the group too.  If
you are the only human working then it only needs to be you.  If you
are working with someone and they need access too then add them too.

Also you will want to set the sgid bits on the directory.  That way
all new files will be automatically set in the group.  The "g+ws"
below means group plus write and set-group-id bit.

  chown www-data /srv/foo
  chmod g+ws /srv/foo

If you already have a lot of directories then use find to find all of
them and set the bit on all of the project directories.

  find /srv/foo -exec chgrp www-data {} +
  find /srv/foo -type d -exec chmod g+ws {} +

And of course to lock them down afterward simply change the user and
group to a different non-privileged user.

  find /srv/foo -exec chown foo:foo {} +

> I know I could easily use GoDaddy hosting, but this will pretty much
> be a static page blog that I'm sure no one will ever visit
> anyway. Also, it gives me the opportunity to learn.

I think this is the best reason to keep moving forward.  If you do it
yourself you might burn your fingers on the forge but you will also
learn how the blacksmithing is done.  So even though I ranted here a
little bit let me encourage you to keep going!  Knowlege is always
useful.  Your small site seems like the perfect place to start.  As
you say, with your small site how bad could it be?  You might get
attacked and cracked.  And if you do then you will learn something in
the process.  But I don't see how any kittens will be harmed.

> In the past, I've always configured my virtual host to use a folder
> in my home directory. I've read that this is better practice, and
> it's always been easier than changing permissions for /var/www, but
> one problem with this is that the www-data user does not have
> permission to this folder.

For your current case I think setting up a directory in /srv/foo is
the better way to do it.  It is more general.  It is easier to keep
things corralled off there.  But sure if it were my own personal blog
and photo album then I would probably host that out of my own home
directory.

> I've been experimenting the last couple of days with giving
> ownership of /var/www to www-data and adding myself to the www-data
> group, but I've had a few hiccups (I'm sure I'm not doing everything
> correctly).

If you didn't have the permissions and setgid bits appropriately then
that is one snag to trip over.  New files will get created and won't
be the right group or file mode.  If you have specific issues I
suggest saying some more words about the problem you encountered.
With something specific I could suggest a specific response.

> I've decided an easier route would be to keep the root web directory
> in my home folder, but change the user that runs Apache to
> myself. I've done some searching to see if this is recommended
> against, but really haven't been able to find too much about the
> issue in general.

I don't like that as much because there are so many things that the
Apache web server can be used for beyond just your own tiny site.  For
example on Debian or Ubuntu it is very easy to 'apt-get install foo'
some useful web enabled package such as "mailgraph" or "gitweb" some
such.  You might not be thinking about it today but then three months
from now you want to give something a try.  If you keep it as per the
default www-data user then they work out of the box.  If you have
changed the runtime to be owned by your uid instead then you have to
keep hacking around that decision forever in the future.

So I would not do that and would keep it running by the www-data user
in a /srv/foo directory.  It is just as easy for you to do since it is
your system.  It keeps things more organized and compartmentalized.

> Is this something that anyone else does on a public server? There
> won't be anything hosted on it that would concern me security wise,
> but it's always nice to know things are as secure as I can make
> them.

People do often and probably inadvisedly give php packages full file
system access.  I can't recall seeing anyone who has run the web
server as them.  But sometimes I do see it running as other random
custom system user.  But at that point any user is as good as another.


Sorry for the long rant.  I rarely get down to this mailing list in my
reading.  I did today and your discussion thread caught my attention
and I was compelled to comment upon it.

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org