
Docker 0-Day Stopped Cold by SELinux - jwildeboer
http://rhelblog.redhat.com/2017/01/13/docker-0-day-stopped-cold-by-selinux
======
bigmac
This post is incorrect. SELinux does not fully mitigate this issue. We
recommend users update to 1.12.6.

I expect Red Hat to issue a retraction shortly. We notified them last night
that this post was incorrect.

Source: Security at Docker.

~~~
otterley
Can you please take some time here to explain why their post was incorrect,
with a brief technical explanation of why SELinux enforcement failed to stop
the attack that exploits the particular vulnerability?

I realize you're busy, but it would be much more helpful than a curt statement
that simply claims they are wrong.

~~~
krakensden
Especially given Docker Inc.'s history of counterproductive Red Hat hostility.

~~~
andrewguenther
This shouldn't be downvoted. Docker has been very openly history towards Red
Hat in the past. To the point of openly mocking their developers at DockerCon.

~~~
shykes
Hi, I'm the founder of Docker. It's not my place to say whether comments
should be downvoted or not, and I don't want to ignite teenage-drama arguments
over who was mean to whom at recess - we get enough of that level of discourse
on the US political scene these days.

But I think there _is_ an interesting topic to address here, that we deal with
a lot at Docker.

The problem in a nutshell: if you choose to take the moral high ground and
only promote your products with positive marketing (and that is our strategy
at Docker - you will never see any Docker marketing content criticizing
competitors), you are vulnerable to bullying and unfair criticism by
competitors who don't mind hitting under the belt. Then the question is: do
you allow yourself to respond and set the record straight? Or would that just
legitimize the criticism by bringing more attention to it? On the other hand,
not responding is also risky because it emboldens the trolls to take more and
more liberties with facts and ethics. This dilemma becomes more and more
pressing as you become more successful and more incumbents start considering
you a possible threat to their business. Some of these incumbents have been
defending their turf for decades by perfecting negative messaging. Like one
competing executive once told me - "we eat startups like yours for breakfast".
This situation can be bad for morale also, because your team sees their work
and reputation dragged in the mud, and can interpret their employer's silence
as a failure to stand up and defend them.

The most perverse variation of this problem is when trolls start _preemptively
painting you as bullies_. If that narrative sticks, then you're in trouble,
because any attempt to set the record straight will be interpreted as
hostility. Now you have two problems: defending yourself against the bullies
AND defending yourself against unfair accusations of being a bully.

The root cause of the problem, I think, is the diminishing importance of facts
and critical reasoning in the tech community. We are all guilty of this: when
was the last time you repeated a factoid about "X doesn't scale", "Y isn't
secure", "I heard Z is really evil" without fact-checking it yourself? Be
honest. Because of this collective failure to do our own thinking and
researching, bullies have a huge first-mover advantage.

I see an direct parallel between the problem of corporate bullying in tech and
the problem of partisan bullying in politics. And I think in both cases, there
is a big unresolved problem: how do you succeed _and_ do the right thing? How
do we collectively change the rules of the game to make bullying and negative
communication a less attractive strategy?

I tried really hard to make this a constructive post about a topic I care
about. If you interpret any of this as hostile or defensive, that is not at
all the intention.

~~~
jwildeboer
When the top comment is a claim that we at Red Hat post incorrect information
and that we at Red Hat are expected to delete said supposedly incorrect
information without any technical explanation on why said information is
incorrect, I do wonder who is the bully in your opinion.

I posted this entry and I work at Red Hat.

~~~
shykes
The post is in fact incorrect. The reason Nathan is not sharing more technical
details is to protect the security of Red Hat users.

Also, if hypothetically the full details made Red Hat look bad, is it fair to
assume you would be calling Nathan hostile for sharing them? In that scenario
is there any course of action we could follow that would satisfy you?

~~~
BeefySwain
>The reason Nathan is not sharing more technical details is to protect the
security of Red Hat users.

Security through obscurity?

~~~
ceejayoz
If you want to be that loose with the definition, passwords and private keys
are "security through obscurity".

Giving people time to patch before releasing the details of how it can be
exploited isn't a bad security practice.

------
CrLf
SELinux used to be one of those things you'd disable immediately upon
installing a new RHEL/CentOS box for all the troubles it would cause. But
default policies have evolved a lot, making this the wrong thing to do, for a
few years now. But people still do it out of habit.

If you ignore SELinux, it won't cause issues besides the ocasional need to run
"restorecon" (which one gets into the habit of doing whenever an "access
denied" error happens when permissions seem otherwise correct).

But one problem still remains. SELinux is (very) complex and people (myself
included) have a very hard time groking its base concepts. This limits
adoption greatly, and I'm still to find a decent document that starts from the
simple stuff and lets one build a mental concept of how it works before
jumping into the more complicated (real-world) use cases.

~~~
gtirloni
_> SELinux is (very) complex and people (myself included) have a very hard
time groking its base concepts._

I wonder what a clean slate OS design would look like. One that satisfied the
same requirements without any concerns about backward compatibility with POSIX
history.

Does anyone know an OS with vaguely this goal?

~~~
binarycrusader
I'm probably biased, but Solaris' role-based access control system has been
very successful among its particular customer base:

[https://docs.oracle.com/cd/E23824_01/html/821-1456/rbac-1.ht...](https://docs.oracle.com/cd/E23824_01/html/821-1456/rbac-1.html)

It wasn't necessary to throw away POSIX history or concerns either.

------
jlhawn
Since when is a security issue which is known to and patched by the vendor a
"0-day"? Have there been any reported exploitations of this vulnerability in
the wild before it was publicly disclosed with a patch made immediately
available?

~~~
justincormack
No, there were not, and it was disclosed to related vendors some weeks
earlier. Some people seem to thing "0 day" is a l33t term for "vulnerability"
it seems.

~~~
jeremyjh
I think all they are suggesting is that running SELinux can protect you from
vulnerabilities that no one knows about yet. Obviously they can't give an
example of an vulnerability that is still a 0 day.

------
giis
SELinux is one of our main protection against user abuse. Our project
(webminal.org) provides free terminal access anyone. Thus we need protection.
Behind the scenes we rely on things like
SELinux/Quota/Pam.d/limits.conf/rootkits etc But SELinux has a learning curve
than others, but its worth a ton.

------
hobarrera
I'm not sure if the situation has changed, but I recall installing Fedora (and
another distro I cannot recall) years ago, and SELinux would kill sshd when a
connection was received, on a clean, out-of-the-box installation, making the
host inaccessible.

These sort of super-critical bug make software go immediately into my
blacklist, and it's very hard to come back from that - it basically meant that
it _had_ to be disabled immediately, because it's defaults were completely
broken.

~~~
chucky_z
I installed Fedora Server 25 a week or so ago on a small server, sshd was open
(with an extremely strong random password) and fully functional at install
time. SELinux has caused no issues, I actually chose to install docker in the
installer at install-time and it came pre-configured to play nice with
SELinux.

Firewalld on the other hand, I'm still figuring out (firewall-cmd is useful,
but trying to translate iptables rules -> firewalld is proving harder than I
expected)

~~~
ams6110
One of the reasons I like OpenBSD. Linux has a habit of taking well
established things and replacing them with incompatible things (firewalld,
systemd for example).

I have enough to do, I don't need to throw away years of acquired experience
every few releases. It's one thing if the replacements are clearly better, but
for me they just seem to be new, different ways to do the same things.

~~~
Gracana
I'd argue that (at least in recent years) OpenBSD does a lot of replacing as
well, but I happen to like their direction, where the replacements are simpler
rather than more complex.

------
throw2016
Selinux is badly designed and it's not suprisingly people don't use it.
Experts are supposed to simplify complexity. You can't design convulated and
complex applications that are user hostile and break things without warning
and then accuse people of laziness. Few who deploy apps take security casually
and selinux is not the only way to gain security.

In a typical scenario when deploying software things can already get hairy and
with selinux in the way you could end up going down multiple rabbit holes and
squander hours only to discover selinux is somehow in the way disabling some
functionality but not logging clearly what exactly it is disabling with proper
messages. That's why most advice online is to disable it.

Given its connected to the NSA and Redhat tried its best to get it into the
kernel at one time is all the more reason for anyone concerned about NSA to
avoid it. Security experts like the author of Grsec also doesn't think too
highly of it.

~~~
ungamed
Spender/GRSec mainly doesn't like it because he has a competing RBAC which
people pay for. It might be better, it might not.. but I don't have a GRSEC
license.

------
sofaofthedamned
Does AppArmor also block this I wonder?

~~~
ajross
AppArmor and SELinux share the same set of LSM hooks underneath, so there's
comparatively little difference in capability. The big fight is over the
philosophy of how they are configured (very broadly: AppArmor tends to
tolerate ad hoc configuration by doing what you want instead of what you say,
and SELinux like to break everything it doesn't understand perfectly).

I really wish SELinux would evolve some better configuration tools/culture,
but after a decade and a half I despair of this ever happening. Every single
Fedora release I leave it enabled on my personal machine thinking "THIS will
be the moment where I really puzzle it out". Then I disable it a week later
when I realize how much annoying work configuring rules for my rando backup
and device management scripting will be, and when I see that it still lacks
rules for a bunch of in-distro tools I need to use.

~~~
brians
Last I looked, Apparmor still applied rules based on file names, not on types
assigned to the underlying objects. That's a big limit on writing correct
policies: every hardlink is like a firewall-spanning device.

~~~
viraptor
I see it mentioned so often, but in practice... is that really an issue for
you? You need to have root privs with unrestricted access (or at least
hardlink creation in the directory explicitly allowed by apparmor) for that.
That means the attack would have to look something like:

1\. gain access to the system (unrelated exploit) 2. elevate to root with
profile which can create hardlinks at all 3. have access to a directory
unrestricted in the profile 4. have local, unrestricted application which can
be exploited by hardlink manipulation

This is theoretically possible on some systems. But it's a massive effort and
fairly easily mitigated by having a profile for all running services which
disallows hardlinks in the first place. As far as risk of service exploitation
goes, this should be a fairly minimal one. (and requires targeted approach)

------
opk
Just a pity that SELinux is widely disabled because it ends up being a pain.

------
astrostl
Productivity is also stopped cold by SELinux :P

