Take Igor Ljubuncic (aka Dedoimedo) for example. He seems to be a smart guy and many look to him for reviews of Linux Distributions. But, I tend to disagree with him about as much as I agree.
His latest story, Linux Mint vs. Ubuntu Security, spurred me to write this post and as it is more than a bit problematic and misguided, I take exception here to disagree with his security recommendation.
As we, in the IT business, should know, security is a process, not a thing. The effectiveness of one Distro's security implementation may or may not be as good as another's. And, how each Distro's developers choose to configure security isn't necessarily guided by good decision making. In fact, I have written, many cookie-cutter clones, or spins if you will, inherit the bad design decisions of their parent Distro, which is one of my pet peeves for why cloning is not necessarily good for Linux at large.
It was causing problems so we disabled it
A response to resolving Linux Security Modules (LSM) issues often heard is the advice given to disable the 'offending' module entirely, when such errors arise.Igor writes:
Aha, I knew it. There you go. Linux Mint does not ship with AppArmor or any profiles. Well, interesting, not. The thing is, security tools like Apparmor or SELinux are much like HIPS software in Windows. In other words, not necessary. Moreover, they usually cause more harm than good by blocking legitimate software from running. What we like to call the false positive, or fail publicly (FP).
Here, Igor takes it upon himself, despite the considerable design efforts put forth by Canonical Ltd. to provide enhanced LSM sandboxing technology, to marginalize the importance of such technology. I find that rather irresponsible, given today's situation, what with world-wide rampant security exploitation and surveillance on the Internet growing by leaps and bounds.
No, I am afraid Igor is giving bad advice and has no business telling readers to disable a service provided by software vendors, backed by good justification and years of experience.
Igor goes on to say:
Indeed, if I look at the history of my involuntary use of Apparmor and SELinux in various distros, I have seen the former kick in only once, and the latter about three dozen times, and each example was a case of a legitimate program being mislabeled. In theory, yes, they might prevent exploits, but you're not running a commercial Web server, so relax.
So, on the one hand, he's admitting that LSMs do indeed prevent exploits, yet on the other he's suggesting (paraphrasing) there was a bug in mislabeling a legitimate application.
So, why, then, did Canonical choose to include LSM AppArmor with Ubuntu and Fedora choose to include LSM SELinux for their several Desktop spins?
Evidence like Stuxnet, Identity Theft, Ransomware, Malware, Bots, Keyloggers ought to be good clues as to the gravity of the situation. This clearly isn't sensational. It is real and happening to the unwary every day. Igor, strangely, minimizes the seriousness of the situation.
What should be done in the case of a reproducible LSM sandbox error?
If you are experiencing a reproducible error (verses a 'one-time' intermittent error) using a signed application in your Distro's software repository, do open a software support call ticket on their website so that the vendor can take immediate corrective action.
Don't disable your LSM sandbox. Go directly to your software vendor for support. Your issues will be resolved expediently with revisions to your security software.
-- Dietrich
0 comments:
Post a Comment