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.
--
Les Mikesell
lesmikesell at gmail.com