> From: Steve Grubb [mailto:linux_4everat_private] > Sent: Monday, February 24, 2003 8:26 AM > There are ways to stop virtual hosted sites from having access to > their neighbors or even having direct access to their own log > files. This can be done through chroot, a sandbox, or jail. The > problem is that all of these protection mechanisms breakdown if > you inherit an open descriptor. Agreed; they may not all directly "break down", depending on how you want to define that, but certainly inherited descriptors are a security problem in general. However: > The jail or sandbox would have to fstat thousands of file > descriptors to see if they are open and close them before exec'ing > the cgi. This is a performance hit and therefore unlikely. No need to fstat them merely to see if they're valid; closing an invalid descriptor doesn't hurt anything on any POSIX platform I know of. Still, depending on the maximum descriptor number available to the process (which should be determined via sysconf, since many platforms allow per-process maximums; it's a ulimit in AIX 5, for example), just closing descriptors 3-max may be a significant operation. I vaguely recall a Samba fix some years ago for AIX for this reason - _POSIX_OPEN_MAX or NFILES or some such system define was a very high number, and each child smbd process was trying to close thousands of descriptors before doing any real work. Some platforms provide a way to whack lots of descriptors in one go; AIX has fcntl(3, F_CLOSEM, 0), which is pretty handy. I think the real way to fix this for CGI is to have the parent process set the F_CLOEXEC flag on all the descriptors it opens, except those that the child is supposed to inherit. Then there's no performance bottleneck, just one additional system call each time a new descriptor is allocated (via open, accept, etc). There are a couple of problems with this approach: it requires vigilance on the part of the developer (but what doesn't, and some profiling with lsof can catch most omissions), and some poorly-designed APIs allocate descriptors but don't tell the caller what they are. A notorious example is the brain-damaged POSIX openlog/syslog API, which has void return type instead of something useful. If openlog is implemented in the obvious fashion, the app should be able to guess what descriptor it's allocated (it should have been the lowest available one), and in any case can find it with some hunting and testing, but it's probably best to avoid syslog or call closelog after every syslog call. Michael Wojcik Principal Software Systems Developer, Micro Focus
This archive was generated by hypermail 2b30 : Tue Feb 25 2003 - 09:23:38 PST