On Mon, Mar 15, 2004 at 12:16:07AM -0500, Paul DeMarco wrote: > I'm looking to get feedback from one of two possible changes to suexec (yes > I know probably the worst thing to suggest changes to). :) > > Both changes hope to mitigate the problem with kernels without ACL support > at the filesystem, on a multi-customer web server. All site files have > global read rights, and combined with CGI support, provides a mechanism to > gain information and even content on site configuration, code, and material > not intended for public access through simple file-system browsing and > reading. > > Also, if there is a solution/work-around to this then please let me know, > and I'll walk away with my head between my legs :)
One possible solution: /pub/u/s/user1/docroot.foo.com/ /pub/u/s/user1/docroot.bar.com/ /pub/u/s/user2/docroot.baz.com/ Have /pub/u/s/user1 owned by user1 and group httpd, permissions 0750 Have /pub/u/s/user2 owned by user2 and group httpd, permissions 0750 Of course, group httpd has no other members other than the web server. Or, if you want to do this on systems where users are members of multiple groups that need access to multiple files. Have /pub/u/s/user[12] owned by httpd but immutable (chattr +i) Have /pub/u/s/user1 owned by a group that user1 is a member of, and likewise for /pub/u/s/user2 and a user2 group. Have permissions 0570 on /pub/u/s/user[12] Another possible solution involves hard-linking directories, which I won't explain here, but you can ask me offline. > Possible Change 1 > ----------------- > Adding a build time option or apache configuration directive that enables > chroot'ing to the users home directory (that is being switched to). This > would be done near the end of suexec's execution, after changing to the > users uid & gid. suEXEC was written to be safe in just about any environment. Adding chroot() increases security in one way, but places much more responsibility on the admin to set up the chroot directories safely. For example, it is not a good idea to have anything in the chroot that runs as root, nor any executable that is setuid anything within the chroot. It _is_ a good idea to mount the filesystem containing the user chroot with the 'nosuid' option and to restrict user access to the top level of the chroot (so that a minimal /dev within can contain secure char and block devices not modifiable by the user) The list goes on... TIMTOWTDI. If you know how to properly configure a chroot, then by all means, adding chroot support to suexec can increase CGI partitioning and security. It is just not a feature that can be added to suexec generically and be safe to use on all systems. If one of the permissions solutions at the top of this email suffices, then I might suggest skipping the complexity of a chroot for each user. You might still chroot all CGI to, say, /pub to protect the rest of the system from "browsing" CGI scripts. > Possible Change 2 > ----------------- > Rather then just switching to the users uid & gid, it would additionally > launch their shell, passing to it the command to execute. I realize there > are implications here since each shell takes a command to execute > differently, and I'm not entirely sure that all do (although all that I'm > aware of do it in a similar manner). > > The goal being that it may be a normal shell, or possibly jail the user > itself. It also has the benefit that it will perform any environment setup > and/or other actions that are set as policy for that user. Terrible idea. Absolutely terrible. Passing a user-supplied command to a shell, possibly with even more untrusted parameters provided by the requesting client, should be avoided wherever possible. What you want to do can most likely be done without invoking a login shell. Solaris SRM (setproject()) FreeBSD login classes (login_getclassbyname(), setclasscontext()) PAM (pam_start(), pam_set_item(), pam_open_session()) can all be added to suexec if so desired, along with jail(), if present. In fact, someone filed a feature request a long time ago for login.conf processing of FreeBSD login classes (http://archive.apache.org/gnats/6673) Invoking a login shell to do the same work under the hood can -- and should -- be avoided. Additionally, Solaris SRM, FreeBSD login classes, and PAM can all be used to apply special limits to CGI that are separate from limits placed on login shells. Cheers, Glenn
