httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <>
Subject Re: WWW Form Bug Report: "suid use of uid/gid is flawed for other models" on Solaris 2.x (fwd)
Date Fri, 06 Dec 1996 06:54:26 GMT

George, the fundamental difference between your approach is that
with your changes, the server must be running as root. This was
not an acceptable risk from the group's point of view, which is
why we choose the wrapper approach. It is much easier to make sure
there are no hidden security holes in the wrapper than there is
to trust the server code itself to run as root.

> [Ben, this is about apache chroot: Jason and Randy did the new code]
> We added gid and uid attributes to virtual server blocks, trivial differences
> in naming compared to your method. Unlike your method, this applies 
> irrespective of setuidbin behaviour.
> In all code locations with a fork/exec (ie calls to spawn_child_err() in
> modules and logging) the daemon instance does a setuid(0) to chroot to
> ServerRoot, and then setuid to the virtual-specific gid/uid instance inside
> the forked child, immediately before the execl() call.
> The setuid(0) is needed to get the chroot/setuid done cleanly, and meant
> the http_main setuid() call to the default user had to be replaced by a
> seteuid to ensure we could regain root privs.
> On reflection and discussion with Ben Golding ( I've
> come to realize that if the SUIDBIN script is called for all execs, and
> if it either takes an extra arg to define where to chroot, or uses
> getpwent to chroot to the users pw_dir path (which is the same thing) we
> probably have equivalent behaviour.
> The difference is that in our case, loosing the on-disk SUIDBIN script cannot
> cause chroot()/setuid to fail. I think this can be resolved by adding a
> -s(ecure) flag to httpd, such that if SUIDBIN is not found on-disk it
> refuses to run. Then it becomes a runtime invokation decision to make the
> daemon have to be run in a trusted manner.
> chroot is orthoganal to setuid but in our case we'd want it also to complete
> before exec was permitted. Its how we ensure indivudual virtual webs cannot
> have visibility of other virtual web on-disk contents. That, coupled to
> a chroot on login and ftp means web developers get a private mini-unix
> tree to work in (we use loopback mounts -r(eadonly) to give them the command
> tree we want them to see.
> I intend testing adding chroot to SUIDBIN script later on, and will send back
> any changes. The flags to make httpd crap out if its not found are pretty
> trivial, as are an extra httpd.conf directive to enable chroot behaviour
> and the overloading of an existing variable to define the chroot path, or
> use of the users passwd file details.
> Does this make sense? Tim Hudson, has also seen the chroot
> code and was looking into making a common chroot stubcall be added into
> code and templates so this was a more generic framework, that would be
> unneccessary if the functionality is added into the wrapper.
> I still have a *few* qualms about the wrapper and trust of its function 
> compared to an embedded call in the daemon, but thats paranoia...
> cheeers
> 	-George

View raw message