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

[Craig White]

On Thu, 2010-05-27 at 05:55 -0700, Jerry Franz wrote:
> On 05/26/2010 08:23 PM, Gordon Messmer wrote:
> > On 05/26/2010 08:44 AM, Benjamin Franz wrote:
> >    
> > [...]
> >> The *theoretical* system security improvement of SELinux is trumped by
> >> the *practical* observation that I have had existing systems broken by
> >> SELinux multiple times on the mere handful of systems I have run it on
> >> in enforcing mode,  but have yet to see a single one of several dozen
> >> (all internet exposed) up-to-date *non*-SELinux systems hacked.
> >>      
> > You are comparing two unlike things.  You can't very well judge the
> > benefits of SELinux based on a system which hasn't needed its protection.
> >
> >    
> 
> I'm comparing a simple metric that applies to *ANY* system admin job:
> 
>           (Downtime)  /  (Machines * Years)
> 
> The metric *DOESN'T CARE* if that downtime is because of bad power, hard 
> drive crashes, hackers,  cosmic rays, SELinux, or poor admining.
> 
> It cares that the services are offline, on how many machines and for how 
> long.
> 
> Arguing that I'm comparing apple and oranges is like claiming that 
> (using my analogy of faulty air bags again) it isn't *meaningful* for me 
> to say that faulty airbags that go off randomly while driving is a 
> bigger hazard than car accidents for me because I haven't had any car 
> crashes specifically needing air bags: The airbag going off randomly 
> while I'm driving is very likely to *cause* a serious car accident 
> itself. I'm measuring *all* serious accidents - not just 'accidents 
> where the airbag might have gone off'.
> 
> A 'safety feature' that *causes* more damage than it prevents isn't a 
> safety feature - it's a hazard. And on otherwise properly maintained 
> systems, SELinux is a hazard.
> 
> >> It is a 'safety' feature that is in practice more dangerous to system
> >> stability than what it is trying to fix.
> >>      
> > I advise administrators to test all updates on non-production systems.
> > SELinux updates are no exception.
> > ______________________________________
> >    
> 
> I have *twenty* virtual machines I deploy updates to before it ever 
> touches my production systems. Not everything is testable on 
> non-production machines. Nor, as the system admin, senior programmer and 
> desktop support person for the entire company do I have the sheer time 
> needed to test every sub-system before deployment. And I shouldn't damn 
> well *need* to on a normal system update to an Enterprise grade 
> distribution (I'm not knocking the CentOS team here - this is about 
> Redhat and SELinux).
> 
> SELinux makes my systems significantly *LESS* reliable instead of *MORE* 
> reliable. And that is a bad thing.
> 
> Now back to fixing the SELinux configuration on a machine I had to put 
> in 'permissive' mode a few weeks ago because the last round of SELinux 
> updates broke the web server's ability to open its own log files. That 
> is what I still have left to fix after having to relabel the entire 
> system to fix the other breakages the update introduced. And no - I'm 
> not kidding or making things up.
----
I guess I don't understand because I have not had to relabel entire
filesystems unless I have disabled SELinux and have never experienced an
update that 'broke' things on CentOS (Fedora is a different issue but
that is more experimental).

Most of the people I see griping about SElinux just don't want to be
bothered with it and just turn it off or they are forced to use it and
don't spend the time learning the tools. It's relatively simple to set
file contexts or policy and I just don't see the downtime being a factor
anywhere.

Craig


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.