From owner-freebsd-questions@FreeBSD.ORG Thu Feb 12 17:44:10 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5684A106564A for ; Thu, 12 Feb 2009 17:44:10 +0000 (UTC) (envelope-from prvs=pauls=2872d2d33@utdallas.edu) Received: from ip-relay-002.utdallas.edu (ip-relay-002.utdallas.edu [129.110.20.112]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE508FC0A for ; Thu, 12 Feb 2009 17:44:09 +0000 (UTC) (envelope-from prvs=pauls=2872d2d33@utdallas.edu) X-Group: RELAYLIST X-IronPort-AV: E=Sophos;i="4.38,198,1233554400"; d="scan'208";a="6393096" Received: from smtp3.utdallas.edu ([129.110.20.110]) by ip-relay-002.utdallas.edu with ESMTP; 12 Feb 2009 11:15:21 -0600 Received: from utd65257.utdallas.edu (utd65257.utdallas.edu [129.110.3.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.utdallas.edu (Postfix) with ESMTPSA id BF4F08A20 for ; Thu, 12 Feb 2009 11:15:21 -0600 (CST) Date: Thu, 12 Feb 2009 11:15:21 -0600 From: Paul Schmehl To: freebsd-questions@freebsd.org Message-ID: 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> <52934.12.68.55.226.1234454699.squirrel@www.academickeys.com> X-Mailer: Mulberry/4.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========9B8CC2F4A5AB55B04512==========" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Restricting users to their own home directories / not letting users view other users files...? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 17:44:10 -0000 --==========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 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==========--