On 05/25/2010 10:44 PM, Les Mikesell wrote:
>
> That still doesn't explain why there is a difference in smbd's context when its
> parent is an explicitly started shell vs. the implict one that starts when the
> script file is executed.
SELinux domain transitions are handled by the kernel. If you call
exec() with a path which has a domain transition specified, the kernel
will transition to the specified domain as part of the exec() call.
What that means here is that /etc/init.d/smbd has a domain transition
specified. If you were to call exec() with that path (as your shell
will when you enter that path alone and hit Enter), the kernel receives
your exec() request, examines the path given, determines that a
transition is defined, and transitions to the new domain as it creates
the new process.
Now, if you call exec() with /bin/sh as the path and /etc/init.d/smbd as
an arg (as your shell will when you enter "/bin/sh /etc/init.d/smbd" and
hit Enter), the kernel will check for a domain transition on /bin/sh and
load that program. The kernel has no knowledge that sh will load
instructions from /etc/init.d/smbd and execute them any more than it
would if you were to run "/bin/sh < /etc/init.d/smbd" in a shell. It
can't determine that it should transition to the domain on that file, so
the process inherits whatever domain called "/bin/sh" (probably the
unconfined domain).
> Isn't the context associated with the program itself,
> not its parent?
The context is inherited from the process which calls exec() if there is
no transition defined. If there is a transition, it is associated with
the path.
> Is this documented anywhere?
Yes, this is the documented behavior of domain transitions.
>
>> That is to say that SELinux does not "want" to block smbd from running.
>> SELinux is intended to describe the access that system daemons like
>> smbd should have in greater detail than mere filesystem access, and to
>> confine smbd to that behavior. Whatever you did caused smbd to start up
>> in some other context (but not unconfined), and was thus confining smbd
>> to the behavior that was appropriate for some other process. It should
>> be obvious why that would cause problems.
>
> From what he has posted so far the "whatever he did" was starting smbd directly
> from a root command line or running the init script with 'sh' or 'bash'.
I meant whatever he did to create /etc/init.d/smbd with an SELinux label
other than the one that rpm originally placed on it. He wasn't specific
about how or where the file was created. It had a label on it which
caused a transition to an SELinux domain other than unconfined or the
one normally used by smbd.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
