[CentOS] Odd failure of smbd to start from init.d - CentOS 5.4 - it's that fine SELinux

Wed May 26 13:01:49 UTC 2010
Ross Walker <rswwalker at gmail.com>

On May 26, 2010, at 1:44 AM, Les Mikesell <lesmikesell at gmail.com> wrote:

> Gordon Messmer wrote:
>>
>> No.  With that file removed, smbd probably wouldn't have been able to
>> write to the directory.  If it was able to, it probably would have  
>> run
>> into trouble with the next file.  If smbd started up in the context
>> which was configured for it, everything would work normally.  If smbd
>> started up in the "unconfined" context, everything would work  
>> normally
>> (but not benefit from SELinux security).  The problem appears to be  
>> that
>> smbd was starting in some other context, which you haven't shared.
>>
>>> Then why was it also happy with "sh /etc/init.d/smb start" but not
>>> "/etc/init.d/smb start". I'm happy to become more educated on  
>>> this. But if
>>> invoking a major daemon startup that selinux wants to block is as  
>>> easy as
>>> that, selinux is window dressing, not security.
>>
>> Your misunderstanding seems to be that SELinux is not intended to
>> prevent an attacker who has root privileges on your system from  
>> starting
>> smbd.  Instead, it is intended to confine the smbd that the system's
>> administrator is running from taking actions which are not allowed by
>> policy.
>
> 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.  Isn't the context associated with the  
> program itself,
> not its parent?  Is this documented anywhere?
>
>> 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'.   Why
> would that give a different context than running the init script  
> with the sh.

These are excellent questions that I wish I knew. I suspect it all has  
to do with how selinux associates processes with security contexts,  
but if someone has a pointer to the details already at hand that would  
be nice.

-Ross