From owner-freebsd-questions@FreeBSD.ORG Sat Aug 2 22:57:27 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 115CA37B401 for ; Sat, 2 Aug 2003 22:57:27 -0700 (PDT) Received: from munk.nu (213-152-51-194.dsl.eclipse.net.uk [213.152.51.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7700043FB1 for ; Sat, 2 Aug 2003 22:57:25 -0700 (PDT) (envelope-from munk@munk.nu) Received: from munk by munk.nu with local (Exim 4.20) id 19jBra-000Mu3-UT; Sun, 03 Aug 2003 06:57:02 +0100 Date: Sun, 3 Aug 2003 06:57:02 +0100 From: Jez Hancock To: freebsd-questions@freebsd.org Message-ID: <20030803055702.GA53660@users.munk.nu> Mail-Followup-To: freebsd-questions@freebsd.org, dt References: <000301c35973$2a11b320$5f4f0844@DT> <20030803050916.GA33525@moo.holy.cow> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030803050916.GA33525@moo.holy.cow> User-Agent: Mutt/1.4.1i Sender: User Munk cc: dt Subject: Re: Need Access Control List(ACL) or any kind of substitute for it X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2003 05:57:27 -0000 On Sat, Aug 02, 2003 at 08:56:05PM -0700, dt wrote: > I recently was able to find a web-hosting company that runs FreeBSD. The > service, I signed up for, allows me to have a SSH access including > series of other services, such as CGI-BIN, Tomcat. On the same machine > that my domain is hosted, there are many other accounts; it's not a > virtual hosting, where I have a root access to my machine. > > On the first day, I discovered that I had to make my files publicly > available so that Apache could pick up my scripts and run them, which I > definitely thought it was not good idea. The only security measures this > company took was that you could not 'ls' up to other people's account, > but I know that if you know the directory structure you can open > anyone's script and look into the content which could reveal a password > and the logic of their code. On top of that, locate-database has all the > directory structure, which is available to anybody. One file permission security model for shared hosting is as follows: Every untrusted user (is there any other!) is added to a common group - say 'users'. Importantly, the user that the webserver runs as - say 'www' - is NOT a member of the 'users' group. The hosting company would then make sure that group permissions on the home directory of each user - say /home/bob for user 'bob' - are set to 705 recursively. This means: - user bob has read write and execute perms on /home/bob as you would expect - anyone in the 'users' group - ie all untrusted users - do NOT have read, write or execute perms on /home/bob and so cannot get a listing of any files under /home/bob - the 'www' user however does have read and execute access to files in bob's public html directory, say /home/bob/public_html and so the webserver can serve up those files as needed. This is a very over-simplified description - there are often log directories or ftp directories or mail directories whose permissions are set to accommodate those services. CGI scripting also complicates matters. With the above model all a malicious (or otherwise) user would have to do to access files in other home directories would be to create a script to display all 'interesting' files in other user's home directories. Something as simple as: for example in PHP would be a start to working out where juicy configuration files that might contain user/password pairs live. If there are no extra httpd side precautions in place, the above security model is pretty useless, since the www user has read/execute access to all /home/user directories and so can execute an operation like the find command above with impunity. Precautions against this type of action commonly include running CGI scripts under the effective user id (EUID) of the owner of the script and in a similar way with PHP, checking that the owner/group of the target files match that of the script being run (using open_basedir and safe_mode amongst other PHP config options). Some things to check then: try running the pwd command - if you see something like /home/user/foo/bar then you're not chrooted. Also try running the id command. See what group(s) you're in and then try 'ls -ld ~' to see what the file permissions are on your home directory. It might be the case your provider is implementing something along the lines of the above. -- Jez http://www.munk.nu/