Is it Okay to Disable SELinux or AppArmor?

I am flabbergasted at what some so-called, self-anointed 'Linux Experts' offer in the way of sound technical advice.

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

Related articles

• Configuring and Managing selinux in Red Hat Linux
• Introduction to AppArmor
• An introduction to security models in Linux

Read More

The Debian Init System Deba{te|cle}

by Dietrich Schmitz

Debian Linux has had a long-standing reputation of being staid and pragmatic in their decision-making.  Even their software release management policy is on the long side when compared with other Distros.  A typical 2-year software cycle just doesn't cut it in today's Internet World operating at the 'speed of light'.

So, it would appear, the time has come for Debian's maintainers to make a decision as to which init system to adopt going forward.

While Debian 7 Squeeze includes systemd as an installable option, the default init system is sysvinit.

The debate currently being conducted at Debian is whether they should move to Upstart (used by Canonical Ltd.'s Ubuntu Linux), or, to systemd instead, going forward and as such a position statement has just been drafted on the Debian wiki site.

Sysvinit Disadvantages

The Debian Team has had many years of good results using sysvinit, but recognize it's limits are now beginning to show strain.  And with a feature freeze for Debian 8 nearing, they must determine which init system will become the new default replacement for the aged sysvinit.  

Here is their list of disadvantages for using sysvinit going forward:

• Sysvinit lacks service supervision. While /etc/inittab provides this capability, management of /etc/inittab is quite restrictive. Upstart eliminates the need for complicated PID file handling for all services. There are bolt-ons that allow you to do service supervision on top of sysvinit, such as runit, but it's clear that these are bolt-ons.
• Sysvinit does not track dependencies between services. Insserv/startpar provides this on top of sysvinit, but this is again very much a bolt-on, and only handles dependencies at boot/shutdown time (i.e., during runlevel changes) and can't handle any complicated service interdependencies at runtime. Upstart expresses this information in the native service configuration format, clearly and concisely.
• Sysvinit requires complex shell scripts for each service. While some of the complexity has been abstracted out into common helpers (lsb-functions; start-stop-daemon), having to represent each service's start/stop handling as a program is a severe handicap. Upstart jobs are simple, declarative, easy to maintain, and easy to modify locally as needed. They also eliminate the longstanding nuisance of update-rc.d reactivating services behind the administrator's back on upgrade.
• Sysvinit is linear. It stopped being a good fit for boot management on Debian the moment Debian adopted udev. There are many race conditions that persist in Debian today when booting with sysvinit, and although these may be fixable, the complexity for fixing them with sysvinit is very high. We're better off switching to an init system that's designed to work together with the event-based kernel and udev.

Upstart vs. SystemD

Clearly, Debian developers recognize that the time has come to make a change.  

In the opinion of the author(s) of the position statement, it would seem to place both init systems on equal footing insofar as features are concerned: 

"In terms of overall feature uplift of the init system itself, there is really rather little to distinguish upstart from systemd. Both would represent a huge step forward for Debian over sysvinit. If Debian did not adopt upstart, systemd would certainly be my second choice."

Looking further for some substantive information in the position statement, the author(s) go on to make some subjective comparisons:

But despite the init systems being comparable at the feature level, there are reasons that I think upstart is a better fit for Debian than systemd.

• SystemD is Linux-specific. Upstream has been very clear that they are not interested in accepting porting patches to enable systemd to be used with kernels other than the Linux kernel. If Debian wishes to continue to support non-Linux ports, this significantly reduces the benefit that maintainers would gain from having a simpler init format to support.

• SystemD is hasty. Debian is late to the party when it comes to adopting a better init system, but systemd is evolving rapidly and does not have a long track record of backwards-compatibility that it can point to. While systemd is unlikely to break any interfaces that upstream has promised to maintain, I think there is a risk that newer dependencies will be driven by the version requirements in Fedora and RHEL, leaving Debian to fend for itself with respect to sorting out rocky transitions on upgrade - not unlike the problematic udev transitions of the past. Upstart is committed to maintaining compatibility across stable releases of Debian, just as it currently does between Ubuntu LTS releases. While upstart seeks to leverage newer kernel features where this makes sense, we are committed to having sane upgrade paths and not depend on such kernel features prematurely.

• SystemD is "greedy". Most of the recent arguments about why it's dangerous to adopt upstart instead of systemd center around features that are being built into systemd in a manner that can't be separated out (e.g., cgroup management in PID 1). There is an advantage to the implementor to put these features in-process in init, because it ensures early availability with no concerns about startup ordering at boot, but it commits downstreams to a monolithic design with respect to parts of the system architecture which are not settled questions in the wider ecosystem. Debian should take a principled position regarding its future architecture, and not find itself at the mercy of other parties who wish to dictate design to us.

So, it is apparent the author(s) are in favor of Upstart but would 'consider' systemd, yet, go on to reinforce with additional reasons why Upstart should be considered over systemd.

As though that were not enough, Google Plus user and Intel employee/Gnome community member +Sriram Ramkrishna  threw his opinion into the mix characterizing the whole subject as having morphed from its original purpose.  Ramkrishna writes:

"...the whole debian systemd discussion has turned into a referendum on GNOME being the default DE for Debian with those who want to switch advocating switching to XFCE as I would imagine that it works closest to what GNOME 2. Why they didn't pick Mate, I don't understand if they want the GNOME 2 experience.

The discussion seems to miss the fact that they would miss out on Wayland and moving to a new display server? They can of course do what they want as that is their prerogative. But it seems that long simmering resentment against GNOME and the change in UI has risen to the fore with the small dependency that GNOME has on systemd. They are using that as an excuse to drive a change in DE.
There are a lot of good reason to use systemd, all that has been rehashed. But the biggest nonsense I've read (as an IT guy) is the fact that we should have a choice in init systems. What the fuck? Essentially people just want to make every part of the OS to be hot swappable. Who would want to support such a system? Who will QA all these combinations? It's madness!..."

However valid the reasons set forth in the Upstart vs. systemd position statement may be, the level of emotion rises whenever a discussion is had concerning moving to +Lennart Poettering's  systemd.  Personally, I believe in the long-term systemd will become the best option receiving full support from the Linux Foundation's kernel.org developers insofar as plans to merge udev and systemd into the kernel are concerned.

The concern is that Debian's pragmatism may work against them and cause a backlog queue of software development issues.  So, acting in a timely fashion in today's world is vital to remaining competitive for any Linux Distribution.  

Hopefully, the Debian Team have recognized this and will respond by making adjustments to how their organizational structure and decision making process works to result in overall efficiency improvements.

As for the Debian init system issue, my money is on Debian going with Upstart, since that was the system chosen by Canonical Ltd. for Ubuntu and Mark Shuttleworth has no intention in making a change any time soon.  This would put both Distros and their derivatives in alignment with each other going forward and efficiencies would obtain.

Here's hoping Debian reaches a decision which best serves their future needs.

-- Dietrich

Related articles

• Debian To Replace SysVinit, Switch To Systemd Or Upstart
• Debian 8.0 To Be Frozen, Features Announced
• Debian To Switch To Systemd Or Upstart

Read More