How best get rid of SELinux?

[Tom Rivers]

Mike McCarty wrote:
> I don't see the analogy. With a building, it makes sense to try to
> salvage a room and/or its content. In the case of a computer, it
> doesn't make much sense to do that. IOW, the building must be completely
> torn down and rebuilt. There is no point in trying to rescue
> some rooms from smoke damage.[*]
>

OK, I see that you are looking at this from an all or nothing approach.  
I would argue that it isn't always the right decision to throw the baby 
out with the bath water, even with a computer system.  Just because one 
part of a thing is broken doesn't mean that the whole thing must be 
trashed.  If that philosophy made sense, doctors wouldn't heal people, 
they'd just shoot them and move on to the next patient.

Here's something to consider.  If you know a machine is compromised, you 
either know what did it or you don't.  If you know the cause, which will 
certainly help you avoid the errors which led to the system being 
compromised in the future, then you simply need to clean up the mess.  
This means that you don't have to trash the whole system to get the job 
done which saves time, money, and sanity.  If, on the other hand, you 
don't know what caused the system to become compromised, then restoring 
the system back to a stable state is a problematic endeavor because you 
haven't fixed what is broken; it is only a matter of time before the 
same thing happens again.  From listening to what you have said on this 
topic on previous occasions, I have the impression that security is a 
serious concern of yours.  To blindly restore the system without 
addressing the root cause is a recipe for disaster as I'm sure you would 
agree.

What this means is one needs to understand both the attack vector as 
well as what damage the intrusion has done.  If you fail to completely 
understand both of these things, you will simply fail again.  In fact, 
if you don't really know what damage has been done and how, you not only 
can't trust the installation media, but you also can't trust any of the 
backups of system files or even user created data either because there 
is no way for you to be sure!

> I believe that ABS attempts to prevent compromise of stability.
>

Actually ABS kicks in a split second after the wheels lock up, after 
stability has already been lost.  It releases the calipers to allow the 
wheel to spin freely for another split second, and then attempts to 
re-engage.
> The only truly secure machine is one which is physically
> secure. Anything else leaves the realm of security, and enters the
> realm of relative security, which is entirely different, and has
> cost/benefit considerations.
>

Technically speaking, a "physically secure" system isn't secure any more 
than an "electronically secure" system is.  In both cases the assertion 
is made that good defenses are in place, but I think you'll be hard 
pressed to find any security professional on the planet who will give a 
100% guarantee even if the system is under lock and key and off the 
Internet entirely.  That's because someone can always break a window, 
pick a lock, or hold your loved ones at gunpoint to gain access.
> Again, inappropriate, for more than one reason.
>
> (1) I don't run a web server.

That's fine, however I bet you have some kind of remote access to your 
system.  If not, then you certainly have decided to take a hard-line 
stance on computer security.  That wouldn't work for a lot of people, 
but if that's the way you want to operate then that's certainly a more 
secure approach.  If you do have remote access to your system, there is 
always the possibility that the program listening on that open port can 
be compromised using the same line of reasoning you employed to identify 
SELinux as being potentially vulnerable.
> (2) Anyone who saves credit card info onto a web server and then gets
> compromised is at best negligent, and possibly criminally negligent.

I'm sure you've heard of zero-day vulnerabilities.  They make it really 
difficult to guard against the unknown and I believe there are 
statistics that indicate attacks of this nature are on the rise.  I'm 
not sure you can logically claim someone is negligent if they fail to 
predict the nature and date of future attacks.  Still, you're right that 
people have to be careful.  That's precisely why SELinux is such a good 
choice.  It seeks to eliminate the avenues of interaction between 
programs and the OS, thus limiting the options a hacked program has with 
respect to doing further damage to the system.  I would even go so far 
as to argue that if one has the option to use SELinux and doesn't, that 
the individual in question could be considered negligent, possibly 
criminally so.  Wouldn't you want the on-line entities with which you do 
business to take every possible precaution with your personal data?  If 
so, then SELinux certainly falls into that category.
> (3) Anyone who lives in the relative security realm, as do most
> of us at least some of the time (I do have absolutely secure machines),
> must assess the cost/benefit of each security measure he implements.
>

I agree completely.
> Wrong analogy, I think. You might feel differently if you installed
> an enormous machine drawing electricity from your house wiring,
> intended to operate a sprinkler system, and the additional load was
> the cause of the fire. SELinux has its own exploits.

Well, I think your analogy fails because the person implementing the 
system should take the power consumption it requires into 
consideration.  Also, your analogy points to the power consumption being 
the cause of the problems and that doesn't track with SELinux because it 
is what's working to prevent problems.

I have been running SELinux for some time and have yet to see a 
performance problem that can be measured.  It may exist, however I 
haven't seen anyone who has any metrics on the drain SELinux has on a 
system.  If you have such information, I would greatly appreciate a 
link.  I would also appreciate some links to information regarding the 
SELinux exploits you mention because I haven't heard of any.
> IMO, trying to mitigate damage is not the proper response. The proper
> response is to keep backups of important data. The system
> itself must not be reintroduced.

As I said earlier, unless you know what caused the system to become 
compromised, you simply cannot expect to be more secure by restoring any 
data at all.  If you restore that important data, you will never know if 
it carries a deadly payload, the kind that was never identified when the 
decision to scrap the system was made.  If you do know what caused it, 
then you can not only be more secure in the future by protecting against 
the threat, but you can also save a significant amount of down-time and 
aggravation reloading everything from scratch.

Blindly scrapping a system and reloading possibly tainted data as a 
result is quite frankly an act of ignorant desperation.  Sure you can go 
back to a time when you didn't see a vulnerability, however that's 
exactly the point - nobody saw it coming in the first place or it 
wouldn't have happened at all!  Only by knowing the threat and the 
damage it has done can anyone be reasonably assured of being in a more 
secure position after the dust has settled.  As Sun Tzu said, "Know thy 
enemy and know thyself and you need not fear the result of 1000 
battles."  ;)


Tom