Hacker News new | past | comments | ask | show | jobs | submit login

Does AppArmor also block this I wonder?



AFAIK as I know, the answer is yes. In fact if you look at the Docker apparmor documentation you can see an example where ptrace was blocked https://docs.docker.com/engine/security/apparmor/


I just want to update this to clarify that it blocks ptrace, but this is only part of the issue and you shouldn't rely on AppArmor to mitigate this CVE entirely.


I think it could.

Here's a write-up showing how AppArmor can protect Docker containers and the underlying host... quote from the article, "So without even patching the container we have prevented rouge pid from spawning using a correct security profile with AppArmor."

    https://scottydoesntknow.io/container-secure-right/


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.


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.


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)


AppArmor is a DAC+MAC and SELinux is an RBAC+MAC. AppArmor is not nearly as powerful. Grsec is much more effective than AppArmor at preventing a wide range of attacks, but SELinux is more or less king.


My understanding is: yes, it is blocked by AppArmor.

Based on seeing email chatter about this report in the context of Cloud Foundry[0]. Under the hood CF uses runC, partly to allow AppArmor to be applied.

Disclosure: I work for Pivotal, the majority contributor of engineering to Cloud Foundry.

[0] https://www.cloudfoundry.org/cve-2016-9962/


I would recommend not giving that advice, and recommend that all your customers upgrade. There are a number of ways to exploit this, and as stated elsewhere on this thread Red Hat's advice that SeLinux entirely mitigates this is not correct, it is highly likely that it can be exploited on Cloud Foundry too. I would never advise people to not upgrade software when there is a CVE because someone says there is a mitigation, it is very high risk.

Disclosure: I worked on testing the fixes for this CVE.


Thanks for your comment. We (Garden - Cloud Foundry container project) released with the runc patch yesterday (https://github.com/cloudfoundry/garden-runc-release/releases...).

It was our understanding from the original report that the vulnerability was mitigated by AppArmor disabling ptrace, by no user process running as pid 1 inside the container, and because in CF buildpack apps, user processes run as unprivileged users. This is the stance communicated in the CVE report.

However, with some further consideration and updated information yesterday, we decided it would be prudent to patch and release immediately to be on the safe side. This was communicated to the Cloud Foundry Security team.


User processes running as unprivileged users may be sufficient to mitigate. AppArmor did not always during testing. But upgrade is highly recommended as there were several ways to exploit and different races, including one related kernel bug that was fixed in very recent releases.


> It was our understanding from the original report that the vulnerability was mitigated by AppArmor disabling ptrace, by no user process running as pid 1 inside the container, and because in CF buildpack apps, user processes run as unprivileged users. This is the stance communicated in the CVE report.

I'd have to think about this further, but I'm not convinced that would be sufficient protection (accessing /proc/$pid/fd has a different set of access requirements to ptrace -- it's a dumpability check basically). However, since you've already sent patches around it's all good.

Disclosure: I discovered, wrote patches for and helped with coordination of this vuln.


Agree. This was the initial stance, when the focus (our misunderstanding) appeared to be on ptrace as the only vulnerability rather than ptrace as the means to easily exploit the vulnerability. Once we had a better understanding, we were also not convinced that this provided total protection.


If you'd like to email me, I can connect you to our security triage team to argue the case.

If we're wrong, we'll change it.

Edit: looks like we already did.


Depends on how well it's configured. My guess is that an out-of-the-box profile probably wouldn't.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: