[CentOS] Odd failure of smbd to start from init.d - CentOS 5.4 - it's that fine SELinux
Jerry Franz
jfranz at freerun.com
Thu May 27 12:55:55 UTC 2010
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.
--
Benjamin Franz
More information about the CentOS
mailing list