Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 18 Sep 2000 17:44:55 +0100 (BST)
From: James Sutherland <jas88@cam.ac.uk>
To: new-httpd@apache.org
Subject: Re: Questions regarding viability of development plan
In-Reply-To: <008101c0210e$9b36ea20$cae50718@plano1.tx.home.com>
Message-ID: <Pine.LNX.4.10.10009181738210.20345-100000@dax.joh.cam.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 17 Sep 2000, John Barrett wrote:

> there is a slight security hole in that perl can switch uid/gid back
> up to root, but I suspect this can be blocked out at the perl level if
> absolutly needed. It has never been an issue here as I write all the
> CGI, I just needed to secure the customers webspaces from other
> customers.

You are changing EUID, I take it, but not RUID, meaning a Perl script
could just do a $> = $< and be back as root? Just setting EUID==RUID
before any exec calls should plug that hole, surely??

> And actually, its not all that hard to patch, coupla changes to allow
> User/Group directives without SUEXEC being detected, getting rid of
> the complaint that apache is running as root, uid/gid changes
> immediatly once the virtual server has been determined from the
> request, and switching back to root at the end of the request.

Not too hard; IMO, it should go in, or at least be better publicised :-)

> I personally dont see any other viable solution, forcing ISPs to run
> everything as external CGI to enforce a security model is just a waste
> of cpu cycles, and using suexec still doesnt address the problem of
> having the customer login own the directory/files for a virtual server
> while still allowing apache to read the files (setting the files to a
> common group isnt a solution, files might as well be world readable if
> everyone with a web account can read all the scripts in other
> customers directories, thereby exposing database passwords, etc).

Agreed. Having per-vhost UIDs is a big plus in some environments...

> The only other solution would be true ACL support on *nix, but the
> most common flavors of *nix dont have ACL support yet (or you have to
> jump through hoops to get it, such as the ACL patches for Linux).
> Given ACLs, you would then be able to give Apache access to the
> webspace no matter who owned the files. (one problem here would be if
> scripts were creating files, they would be owned by apache, and not
> the customer, just another stumbling block that changing uid/gid
> doesnt run into)

Hrmm... nah. That doesn't solve very much, really. The main issue is with
scripting; if you want a file to be private, don't put it in a ... WWW
document root!!

> All the screaming about buffer overrun threats and root hacks from the
> dev team is understandable, but it makes me wonder about their
> confidence in the core request code. I seems to me it should be easy
> enough to make sure that there are no holes in the basic core. In any
> case, the changes could be wrapped up as a configuration option so
> that only people that want this functionality get it. Everyone else
> would see Apache "the way it is" :)

This shouldn't introduce new any security issues - it should be equivalent
to simply running one server per vhost, each running with a different UID,
only more efficient.

> So I'll join with Lynn and all the other folks that have requested Per
> Virtual UID/GID support, its an idea whose time has come !!!

Agreed - particularly if there's a decent security audit beforehand...


James.