On May 25, 2010, at 9:44 PM, Whit Blauvelt <whit at transpect.com> wrote: > On Tue, May 25, 2010 at 08:52:58PM -0400, Ross Walker wrote: > >> Selinux alerts are in /var/log/audit/audit.log > > Thank you for that. Cryptic, but there it is. > >> The problem is if smbd doesn't create the messages.tdb file then it >> won't have the selinux rights. > > I don't follow you. What else could have ever created the > messages.tbd file? > These were virgin OS installs. Whatever's in /var/cache/samba, at > the time > that smbd wouldn't run - which is right of the bat or at least as > soon as it > mattered to us, after our config was in place - is there only > because either > the CentOS install, or samba itself in trying to start it from > /etc/init.d/smb, put it there. What else could have ever created > messages.tbd than smbd? I was under the impression that the config might have been copied in including what might be in /var/cache/samba, but if it wasn't then maybe it was the joining the machine to the domain, which also creates a messages.tdb file. > If selinux's real complaint is that it doesn't like the files in / > etc/samba > being copied in from another system, that would make some sense - > except > that I'm not finding any mention of any of those files in the audit > logs. > And that still doesn't say why it starts having a problem with > /var/cache/samba/messages.tbd. Does it? Best guess is joining the machine to the domain under root context caused the cache files to be created under the root context. >> That file can be deleted and will be recreated on smbd start, it's >> just a cache file. > > So in theory if I'd nuked that file smbd would have been happy? Yup, in fact I don't know why the cache files that don't need to persist aren't removed on service shutdown. > 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. When passing the script into a shell run under root context the script was actually run under root context, when executing the script directly (invoking the shell indirectly) it ran under smbd context. Selinux is there to help prevent what happens within a security context, but running things as root can accidentally elevate a program's context. Maybe sudo can help here? > What am I missing about how that's anything like useful? Selinux is a strange beast, but it's one of those things once you set it right you can pretty much forget it. -Ross