On Wed, Oct 27, 2004 at 10:46:51AM -0400, Stephen Smalley wrote:
> 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.
This makes sense, thanks to you and Colin for explaining this through.
It was just the fact that I thought Colin wanted to split up the code
which confused me :)
> 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.
Using 2>&1 | cat does change the behaviour though which is what I think
we should be trying to avoid: it loses the exit value and it loses
stdout/stderr separation.
I like the idea of using runcon to do this. It looks like:
if selinuxenabled; then
runcon -- `id -Z` $HTTPD -t
else
$HTTPD -t
fi
will DTRT for when SELinux is disabled, too. So is this a general
enough solution that I can integrate it: no more gotchas?
Regards,
joe