Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Feb 2009 11:15:21 -0600
From:      Paul Schmehl <pauls@utdallas.edu>
To:        freebsd-questions@freebsd.org
Subject:   Re: Restricting users to their own home directories / not letting  users view other users files...?
Message-ID:  <BE0B52A92B1794E7697D8DA3@utd65257.utdallas.edu>
In-Reply-To: <52934.12.68.55.226.1234454699.squirrel@www.academickeys.com>
References:  <53134.12.68.55.226.1234369337.squirrel@www.academickeys.com> <20090211181843.GA41237@slackbox.xs4all.nl> <65534.12.68.55.226.1234377513.squirrel@www.academickeys.com> <F41F7727070FF48ED4A2BCB1@utd65257.utdallas.edu> <52934.12.68.55.226.1234454699.squirrel@www.academickeys.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--==========9B8CC2F4A5AB55B04512==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On Thursday, February 12, 2009 10:04:59 -0600 Keith Palmer=20
<keith@academickeys.com> wrote:

>
>
> Your other proposed solution results in the same situation, correct? No
> matter what, Apache needs read-access to any and all files, so no matter
> what PHP will have access to read any user's files. There's no way around
> that for a shared hosting situation that I know of...
>
> If you remove the groups write privs, then PHP scripts can't really do any
> damage at least.
>
>
> Your solution doesn't work because the user "keith" could still do a "ls
> /home/shannon/public_html/" and get the directory listing (shannon's
> public_html directory is 0755, per your suggestion). Unless I'm missing
> something...?
>

If you set the world readable bit, you break the entire schema.  To make it=20
work, world must have no access - not even directory search access.  So you set =

u=3Drwx,g=3Dsrx,o-rwx (or 2750), for homedirs and u=3Drw,g=3Dsr,o-rwx (or 2640) =
for=20
files.  To maintain the schema you would also need to change the users' umask=20
to 027 or (script a perm change periodically to remove the world bits from new=20
files.)

If you want to get more granular, you can set the homedirs and all subdirs to=20
owner:owner and only set the public_html dir and its subdirs to owner:www.  The =

key is to remove the world access from the homedirs and everything under them,=20
set the group to www, setgid and change the umask.  Once you've done that, it's =

pretty much maintenance free.  It wouldn't hurt to script something that crawls =

the homedirs periodically looking for perm problems, just in case something=20
crops up.

The webserver only needs read access to files (unless the application you're=20
running has some special requirements.)  You can make a perl script (or php=20
files, python, tcl, you name it) read only and then configure Apache so it's=20
executable from within Apache but not directly from the hard drive.

Most application vendors tend to "err" on the side of too-loose perms,=20
demanding rwx for everything when that's really not needed.  You can play=20
around with the perms and see what breaks, then roll the new set out once=20
you've figured out what's needed.  But, if you do it right, world doesn't need=20
any access at all, and that's going to be a requirement going forward to keep=20
others from seeing the files.  If world has access, anyone on the server has=20
access.

The webserver I maintain has no access at all for world.  Individual dirs may=20
have differing access rights depending upon who needs to get into them, but=20
world is excluded.  This means an attacker has to become root or the webserver=20
user before he can even see the web stuff, and only root would have more than=20
read access.

If the web server has read only access to the files, then an attacker is=20
limited to exploiting vulnerabilities in the webserver or the applications=20
running on it.

I strongly suggest you install and use mod_security (if you're not already) to=20
protect against that.  It's very lightweight and works quite well.  There's an=20
active user community, and you can protect against existing vulnerabilities=20
with the right filters in place.

--=20
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

--==========9B8CC2F4A5AB55B04512==========--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE0B52A92B1794E7697D8DA3>