[webapps] PHP files owner

[Tomasz Pala]

On Tue, Jun 12, 2007 at 07:01:38PM +0200, Pawel Golaszewski wrote:
> 
> ...which will be droped in future php releases :)
> safe_mode is considered to be obsolete in PHP.

I know. However there's no rational replacement AFAIK and I doubt people
will happily switch to new version. I won't until it's ready.
Anything I read says how safe_mode is bad and that server should be
PROPERLY configured, but none has said what does it mean. I can think of:
- vserver for every user (imagine 1000+ users - not so big machine),
- open_basedir for every system account (as above, shitty idea as long
  as there's no system-wide globbing variable, e.g.
  open_basedir = "$HOME:/tmp", preferably with session.save_path="$HOME/tmp"
  and upload_tmp_dir="$HOME/tmp" for every user OWNING script, again),
- PHP as CGI run via suexec - performance penalty, but the only one solution
  solving problem of inherited EUID for exec(), system() etc.
Well, there's also possibility of modularized PHP to gain OWNING user
rights, but this should be considered as The Most Evil and Stupid Idea.

I've got ACLs on my server, but as long as every PHP script is run as
the same http system user they do no user separation at this level. It's
odd, that logged user Joe can do literally nothing with Bill's files,
but (without safe_mode) can read something via PHP script (no matter how
did he guess filename or path, reading should not be able at all).

How can I prevent Joe from reading Bill's files?
How can I prevent Joe from running his own (uploaded) programs?
How can I prevent Joe from reading my password from
	/etc/webapps/coppermine-gallery/config.inc.php
	without safe_mode?

> I see that you have started implementing open_basedir and I think that we 
> should follow this way. Any restrictions, even very wide by default, would 
> be nice.

That's what I thought. But this helps only for system packages. Joe can
install anything on his own and I don't want to create dozens of
open_basedir rules for every system account I've got. Without safe_mode
I would be forced to.

> > Currently system-wide package creates bigger threat than any user 
> > script, no matter how the environment IS secured (safe_mode, suexec PHP 
> > as CGI etc.). Shouldn't we change default root:root owner to some 
> > webapps:webapps?
> 
> What will it give us? I don't get the point in this moment...

In short - some priviledges are inherited from script owner (at
application level in safe_mode or system level with suPHP or
suexec+PHP-f?CGI). Thus we should make them ordinary.

Assuming a bug in any webapp, e.g. seeking to any file or executing a
binary:
- safe_mode - as long as root is the owner, an attacker can read root's
  files having o+r or (g=http)+r, e.g. /etc/passwd or files containing
  database passwords: /etc/webapps/coppermine-gallery/config.inc.php,
  /etc/webapps/mediawiki/AdminSettings.php,
  /etc/webapps/phpMyAdmin/config.inc.php, /etc/webapps/phpwiki/config.ini,
  /etc/webapps/stacks-wiki/db.php, /etc/webapps/zabbix/db.inc.php
  Changing script owner makes safe_mode block this[1]. For now open_basedir
  does it too, but as it is application-level security I don't trust it
  (there were bugs) and IMHO it would be better to have them two work
  together,
- suPHP and any other solution involving EUID changes - they are all
  SUID and it's obvious, that the sooner they drop to ordinary user
  (script owner) the better. Why give them a chance to stay and work
  with EUID=0? And this time the threat is bigger (although the system
  seems to be more secure! for users at least) - it includes not only
  reading some files, but also executing a code with root priviledges.

My conclusion: there are some paths of priviledges propagation from
script owners. However the risk is low and dependant of system
configuration, we shall avoid it. We should not trust separation above
operating system.

[1] even more - we must set safe_mode_include_dir for every application
so that is could read it's configuration file. This way we are sure that
no other PHP script will have access.

-- 
Tom Pala <gotar at pld-linux.org>           http://vfmg.sourceforge.net/
                                         http://tccs.sourceforge.net/