[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: How best get rid of SELinux?
- From: Tom Rivers <tom impact-crater com>
- To: For users of Fedora <fedora-list redhat com>
- Subject: Re: How best get rid of SELinux?
- Date: Fri, 21 Sep 2007 16:21:38 -0400
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
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
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
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
[Date Prev][Date Next] [Thread Prev][Thread Next]