Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Aug 2003 06:57:02 +0100
From:      Jez Hancock <jez.hancock@munk.nu>
To:        freebsd-questions@freebsd.org
Cc:        dt <dt@arbuz.com>
Subject:   Re: Need Access Control List(ACL) or any kind of substitute for it
Message-ID:  <20030803055702.GA53660@users.munk.nu>
In-Reply-To: <20030803050916.GA33525@moo.holy.cow>
References:  <000301c35973$2a11b320$5f4f0844@DT> <20030803050916.GA33525@moo.holy.cow>

next in thread | previous in thread | raw e-mail | index | archive | help
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. 
<snip>

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:

<?php
$find=`find /home -iname "*config*"`;
print $find;
?>

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/


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