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/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
