Unix administration - User directory security

Author

User directory security

2004-06-11, 5:35 pm

There is a security issue between Unix system and Apache web server.

We have many users in our Unix system, i.e. user1, user2 with home directory
/home/user1, /home/user2.
An apache server (running as 'nobody') provides user directories, i.e.
http://mydomain.com/~user1 and http://mydomain.com/~user2

user1 has a php file under /home/user1/public_html/secret.php with
permission (+acl), i.e. http://mydomain.com/~user1/secret.php

# file: secret.php
# owner: cstest
# group: misc
user::rwx
user:nobody:r-x #effective:r--
group::--- #effective:---
mask:r--
other:---

With the acl control, only 'nobody' (i.e. the web server ) have permission
to read this file.
NO other users can logon the workstation, 'cd' to the directory and see the
source of this file.

However, user2 can easily get the source code (secret.php from user1) with
the following code,
not just the web/php output

<?php
@readfile("../../user1/public_html/secret.php");
?>

This is because the web server also run this code in 'nobody'. 'nobody' can
steal the source code !

Is there any solution to protect this issue ?
any comment ? Thanks.

Isaac To

2004-06-11, 5:35 pm

>>>>> "JK" == JK <jk6ft2-forum@yahoo.com> writes:

JK> Is there any solution to protect this issue ? any comment ? Thanks.

It is completely wrong to grant permission because a certain creditial is
*lacking*. The whole Unix security scheme does not work that way, and there
will be a never ending stream of holes that allow users to hide their
creditial and "steal" the file. Permissions must be granted because the
accessor *has*, rather than *does not have*, some creditial. You might want
to allocate a group for the web server and create a script owned by the web
server that allow users to change their files to this group (without
allowing other users to view them at the same time). This way you can
easily prove to yourselves that the scheme would actually work independent
of what is happening in the other end of the world.

Regards,
Isaac.

Isaac To

2004-06-11, 5:35 pm

>>>>> "Isaac" == Isaac To <kkto@csis.hku.hk> writes:
[vbcol=seagreen]
JK> Is there any solution to protect this issue ? any comment ? Thanks.

Isaac> It is completely wrong to grant permission because a certain
Isaac> creditial is *lacking*.

I must be having trouble with my sleep pattern... the OP actually have a
scheme that grant permission because a creditial is there. Please ignore my
post.

Regards,
Isaac.

those who know me have no need of my name

2004-06-11, 5:35 pm

in comp.unix.admin i read:

>There is a security issue between Unix system and Apache web server.

the security issue is more about your use of a particular add-in module.

[any user can obtain another's ...]
>source code (secret.php from user1) with
>the following code, not just the web/php output
>
><?php
>@readfile("../../user1/public_html/secret.php");
>?>
>
>This is because the web server also run this code in 'nobody'.

>Is there any solution to protect this issue ?

don't use mod_php, use the cgi sapi and suexec instead. or try one of the
many attempts to cope, e.g., mod_suphp. or make an open_basedir setting
for every user.

--
a signature

Alvaro G Vicario

2004-06-11, 5:35 pm

*** JK wrote/escribió (Fri, 11 Jun 2004 15:29:15 +0800):
> Is there any solution to protect this issue ?
> any comment ? Thanks.

Add this to your Apache virtual host:

php_admin_value open_basedir /home/username/:/var/common/inc/:/tmp/

Add a colon-separated list of allowed dirs for each one.

--
--
-- Álvaro G. Vicario - Burgos, Spain
--

Dik T. Winter

2004-06-11, 5:35 pm

In article <1086938885.743723@bernard> "JK" <jk6ft2-forum@yahoo.com> writes:
> There is a security issue between Unix system and Apache web server.

Not inherently, only in the way you set it up.

> We have many users in our Unix system, i.e. user1, user2 with home directory
> /home/user1, /home/user2.
> An apache server (running as 'nobody') provides user directories, i.e.
> http://mydomain.com/~user1 and http://mydomain.com/~user2

This is asking for problems, as you note. Apparently 'nobody' has
permissions 'user2' does not have. In that case it is a bad idea
to let 'nobody' execute scripts and/or programs owned (and written)
by 'user2', because that way 'user2' can get the same permissions
as 'nobody' has (provided he can force 'nobody' to execute the
script/program).

Scripts and programs owned by 'user2' should be executed under the
user-id 'user2', not something else, in that case.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

Michael Vilain

2004-06-11, 5:35 pm

In article <m1ekoma2pp.gnus@usa.net>,
those who know me have no need of my name <not-a-real-address@usa.net>
wrote:

> in comp.unix.admin i read:
>
>
> the security issue is more about your use of a particular add-in module.
>
> [any user can obtain another's ...]
>
>
> don't use mod_php, use the cgi sapi and suexec instead. or try one of the
> many attempts to cope, e.g., mod_suphp. or make an open_basedir setting
> for every user.

When I need to only allow my account to have access to a file, I set the
permissions accordingly (no ACL's on our system) and have the web server
access it using a CGI script called through CGIwrap:

http://cgiwrap.sourceforge.net/

This allows the web server to run my UID rather than nobody.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Gandalf Parker

2004-06-12, 11:53 pm

those who know me have no need of my name <not-a-real-address@usa.net>
wrote in news:m13c516aas.gnus@usa.net:

> in comp.unix.admin i read:
>
>
> cgiwrap is an excellent alternative to suexec. it can even run php
> scripts without them being `normally executable' (with a shebang line
> and with execute permission), i.e., it can remain the same sort of php
> file that `everyone' expects (starts with <? and is mode 644 or so).
>

I tend to think as a sysadmin upward rather than web or program downward
to the system. I find that I have more control and security if I have a
program or cgi or web-page create a file with the information in it. Then
have a CRON job look for the file in order to process it. Alot of the
more confusing security checks are not needed with that method.

Gandalf Parker
-- Have you ever noticed that the Klingons are all speaking unix?
"Grep ls awk chmod." "Mknod ksh tar imap."
"Wall fsck yacc!" (that last is obviously a curse of some sort)

Igmar Palsenberg

2004-06-20, 10:31 pm

those who know me have no need of my name wrote:

> don't use mod_php, use the cgi sapi and suexec instead. or try one of the
> many attempts to cope, e.g., mod_suphp. or make an open_basedir setting
> for every user.

Or use mod_suid, or Apache 2.

Igmar

Stachu 'Dozzie' K.

2004-06-26, 10:10 am

On 2004-06-11, JK wrote:
> There is a security issue between Unix system and Apache web server.
>
> We have many users in our Unix system, i.e. user1, user2 with home directory
> /home/user1, /home/user2.
> An apache server (running as 'nobody') provides user directories, i.e.
> http://mydomain.com/~user1 and http://mydomain.com/~user2
>
> user1 has a php file under /home/user1/public_html/secret.php with
> permission (+acl), i.e. http://mydomain.com/~user1/secret.php
>
> # file: secret.php
> # owner: cstest
> # group: misc
> user::rwx
> user:nobody:r-x #effective:r--
> group::--- #effective:---
> mask:r--
> other:---
>
> With the acl control, only 'nobody' (i.e. the web server ) have permission
> to read this file.
> NO other users can logon the workstation, 'cd' to the directory and see the
> source of this file.
>
> However, user2 can easily get the source code (secret.php from user1) with
> the following code,
> not just the web/php output
>
><?php
> @readfile("../../user1/public_html/secret.php");
> ?>
>
> This is because the web server also run this code in 'nobody'. 'nobody' can
> steal the source code !
>
> Is there any solution to protect this issue ?
> any comment ? Thanks.

I've just read answers you've got and nobody tells you solution for
mod_php. You have to enable safe_mode in php.ini. This doesn't allow
reading files which belong to one user by scripts which belong to
another user. Quite useful thing

--
Stanislaw Klekot