On Wed, 2004-10-27 at 10:30, Joe Orton wrote: > I'm still trying to understand your suggestion to move the bits of code > which do "config testing" into a separate /usr/sbin/httpd-configtest > binary, and how that would avoid the issue. I bring up PHP as an > example of why this isn't really feasible: the code which involves > "config testing" is spread all through the modules, so isn't really > separable. Using separate front-end binaries for the different purposes, even if they share much of the same code, allows SELinux to automatically distinguish them, e.g. performing a security transition upon exec'ing the daemon to confine it while not performing a security transition upon exec'ing the config-testing program. In this case, you don't expect the config testing code itself to be malicious; you are just concerned about subversion of the daemon after it is exposed to the network. SELinux only performs security transitions on exec, as that is the point at which one can control inheritance of state and the initialization of the process in the new security context. One can also suppress a security transition (subject to policy, of course), e.g. runcon -- `id -Z` /usr/sbin/httpd -t forces it to run in your current context rather than transitioning, although doing that is a bit complicated here by the indirection of several scripts. Easier in this case to just pipe the output to the caller and let it display it as Colin did. -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency