Re: [TCLUG:6653] httpd ownership

[JellyD <jellyd@jellyd.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 21 Jun 1999, Tim Wilson wrote:

> I've got a question about httpd. RedHat (and others I suspect) install
> Apache so that root owns all the relevant files, directories, and daemons.
> I've been reading "The Apache Bible" by Kamir (I think that's his name),
> and he suggests that you should create a special 'httpd' user for Apache.
> Could someone elaborate on the pros and cons in this case? Also, is there
> an easy way to change ownership of all things related to Apache at once?

I don't know about particular things they were referring to,
but I just moved _all_ my non-localuser-authenticating daemons
(and even some of those) to non-root accounts, all with ports >
1024. It was a rather convoluted change, but I've got most of
it working now. I just did Apache this evening, in fact.

Here's what I did:

+ Set all ports Apache uses to be originalPort + 10000 (my
range for these non-root ports, which I firewall off from the outside
and use packet-redirection rules with ipchains to move the packets to),
which on my server is port 80 and port 443 (ssl3).

+ Make a user for apache to run on; I actually had it running
as user www.www for a while (but root still had to execute the
apachectl script so it could bind port 80). Now it's
httpd.minions (which takes a bit of explanation, which is at
bottom).

+ Make user httpd.minion's home directory to be /pseudoroot/httpd,
and put what used to be the /usr/local/apache subtree in that directory.

+ Change the ownership on all files related to httpd (which should now all
be in the /pseudoroot/httpd directory on my machine) to be owned by
httpd.minions:

    # chown -R httpd.minions /pseudroot/httpd

+ On my system, I also had to copy the /usr/local/jserv tree (and its related
directories) to under this directory, and chmod'd them accordingly), because I
run my Apache with the mod_jserv (Java Servlets) module.

+ Add ipchains routing rules for httpd:

    # ipchains -I input -s 0.0.0.0/0 -d <your ip> 80 \
            -j REDIRECT 10080 (or whatever your new port is)
    # ipchains -I input -s 0.0.0.0/0 -d <your ip> 443 \
            -j REDIRECT 10443 (or whatever your ssl3 port is now)

+ I'm actually going to be implementing a secondary chain to put the
redirection rules into, which will allow greater control (disabling external
access to these ports, or filtering packets according to some ruleset) before
actually applying the redirection.




:[ Explanation of the minions ; skip this if you don't care ]:

I made a /pseudoroot directory which contain the home directories for all of
my newly-non-root daemons. Each daemon has a username called `daemonname`
(httpd, identd, etc.) and a home directory of /pseudoroot/`daemonname
(/pseudoroot/httpd, in this example). They all share a common group,
'minions', which has GID 10000. Each daemon has a UID of 10000+x,
incrementally (not corresponding to the ports, right now), and their only
group is minions.

Oh, there's also one more user, master.minions, which acts as the lord of the
minions. (I would've called them daemons but I didn't want a 'daemons' group
as well as the stock 'daemon' group, for clarity.) His home directory is
/pseudoroot/master, and his UID is 10001 (the first minion).

Among other things, the /pseudoroot tree appears to be a normal root
partition, containing its own /bin, /etc, /usr, /var, /lib, and /dev
directories. I'm going to munge on the kernel sources so they can have
their own /dev/null special file (I don't like the idea of symlinking out
of the root; it should be standalone).

I'm in the process of moving even the authentication daemons to unprivileged
ports (as minions) as well; I think I'll end up implementing this by copying
the /etc/passwd and /etc/shadow files to the /pseudoroot/etc subtree, and
removing accounts from the file that never login remotely (root, bin, etc.).

Ideally, I plan to write a small shell for these users that sets their
effective root directory to be the /pseudoroot directory (a chroot, in
essence). That way, if any of the daemons are exploited, they'll only allow
the cracker to play with things in the /pseudoroot tree, which ideally resides
on a separate physical disk/partition, etc. Also, other than the
publicly-accessible files, system damage is minimal, requiring at most (other
than reconstruction from some backups) requiring a mass password change of all
the users.

Or rather, that was the plan, until moments ago. Now that I think about it,
that wouldn't work at all, because that would require the users' home
directories to be mounted somewhere under the /pseudoroot tree, and then
there's no real benefit from moving to unprivileged users, other than that
the cracker can't take down the system from a normal user account.

I've been chewing on the sources for all of the affected programs recently,
moving them away from using paths like /var/adm/wtmp and pointing them to
/pseudoroot/var/adm/wtmp, but if a chroot'd shell worked, they wouldn't even
need to have their source modified.



There are a lot of inherent flaws with what I'm doing, but I'll be trying to
work them out. Comments welcome, of course.

- --
[----------------------------------------------------------------------]
| Joshua Becker                    - aka -                      JellyD |
| email: jellyd@jellyd.org                          IRC: EFnet, DALnet |
[----------------------------------------------------------------------]

-----BEGIN PGP SIGNATURE-----
Version: GNUPG v0.4.3 (GNU/Linux)
Comment: For info finger gcrypt@ftp.guug.de

iD8DBQE3bu6tcmkpI69BOLwRAjAJAJ9v7aLHLPNPMgHuQnR1xCxKTsKQHgCbBbaK
Eco9z7+Kl4k273jlqyYRoGM=
=04/o
-----END PGP SIGNATURE-----