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
