On May 26, 2010, at 1:44 AM, Les Mikesell <lesmikesell@xxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
