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