dhcp apparmor profile complains about lxd client

Bug #1654624 reported by Hadmut Danisch on 2017-01-06
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
High
Unassigned
isc-dhcp (Ubuntu)
High
Unassigned

Bug Description

Hi,

strange problem recently occured:

I'm having some ubuntu machines running in LXD (nothing unusual, just based on the regular ubuntu LXD images) on a ubuntu host. Worked well for some time.

But now the host generates messages like

Jan 6 19:17:05 monstrum kernel: [ 1063.263531] audit: type=1400 audit(1483726625.388:247): apparmor="DENIED" operation="file_perm" namespace="root//lxd-rackadmin_<var-lib-lxd>" profile="/sbin/dhclient" name="/apparmor/.null" pid=5125 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=165536 ouid=0

in /var/log/kern.log.

For some reason the apparmor running on the host interferes with the containers.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: isc-dhcp-client 4.3.3-5ubuntu12.6
ProcVersionSignature: Ubuntu 4.4.0-57.78-generic 4.4.35
Uname: Linux 4.4.0-57-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.4
Architecture: amd64
CurrentDesktop: LXDE
Date: Fri Jan 6 19:19:12 2017
SourcePackage: isc-dhcp
UpgradeStatus: Upgraded to xenial on 2016-04-06 (275 days ago)

Hadmut Danisch (hadmut) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in isc-dhcp (Ubuntu):
status: New → Confirmed

Which are the perceivable consequences of this bug?

When answered please set status back to "confirmed". Thank you.

summary: - dhcp apparmor profile comlains about lxd client
+ dhcp apparmor profile complains about lxd client
Changed in isc-dhcp (Ubuntu):
status: Confirmed → Incomplete
Stéphane Graber (stgraber) wrote :

Removing the LXD task, this is yet another apparmor bug from the apparmor stacking/namespacing change which was backported to Xenial.

Basically, dhclient is now being confined by apparmor inside the container, unfortunately, apparmor doesn't behave in the exact same way when it's interpreting a profile as part of a stack vs as the single profile in the stack (on the host).

We've seen a number of file_perm and related issue show up, typically related to permissions to access the failing binary itself. Though in this case, the path does seem a bit weirder?

Anyway, not a LXD bug but an apparmor one. I'm sure John will have an idea of what's going on here :)

no longer affects: lxd (Ubuntu)
Hadmut Danisch (hadmut) wrote :

> Removing the LXD task, this is yet another apparmor bug from the apparmor stacking/namespacing change which was backported to Xenial.

Well, that explains a lot. 16.04 was formerly stable but recently began to drive me crazy because of so many apparmor problems with almost every major daemon or browser, and an aa-notify which just vomates hundreds of messages onto the desktop faster than one can click them away.

I am not an apparmor expert, but was able to deal with it for years, but suddenly have the problem that adding permissions to the local-files for local extensions does not solve problems as expected.

I think it is not overestimated to say that this apparmor thing broke the usability of 16.04.

What in the world was the reason to backport these problems into a stable release?

Hadmut Danisch (hadmut) wrote :

> Which are the perceivable consequences of this bug?

I currently cannot survey the consequences, since I am not familiar with the recent semantic changes of apparmor (are there any docs? Any hints to the users about changes? Any release notes?)

For some time now I am spending and wasting lots of time to hunt bugs in all sorts of software like firefox, chromium, ejabberd, lxd,... which is all caused by sudden apparmor trouble.

A side effect of all these bugs is that log files (and desktops through aa-notify) are flooded with hundres, thousands, millions of log messages, which jams a system and makes it impossible to find really important log messages, and, btw., can ruin flash memory in SSDs and SD-Cards within short time.

Why on earth has one backported this pile of bugs into a LTS version?

This rendered Ubuntu so unreliable, that I have to consider to change to CentOS or something like this for servers in order to get SELinux instead.

Is there any way to get 16.04 stable again?

BTW: How should I answer the question about the consequences of the bug, if I don't see any docs about was has changed with apparmor?

Changed in isc-dhcp (Ubuntu):
status: Incomplete → Confirmed
Changed in isc-dhcp (Ubuntu):
importance: Undecided → High
Changed in apparmor (Ubuntu):
importance: Undecided → High
status: New → Confirmed
tags: added: regression-update
Seth Arnold (seth-arnold) wrote :

Hadmut, AppArmor's stacking support was intended to allow supporting unmodified Ubuntu inside LXD containers. If you're feeling up for some experimentation, you could try to disable this feature by setting the kernel.unprivileged_userns_apparmor_policy sysctl to 0 early in a system boot, preferably before LXD starts. This should cause the attempts to set policy within LXDs to fail, and either the services will then refuse to start or they'll fall back to their old behaviour. (This reflects my lack of familiarity with LXD.)

I'll note that this is a wild guess; I'd feel more comfortable giving this advice on IRC than in a public bug tracker where it might do more harm than good. But I'm cautiously optimistic that this might give you a system you'd be happier using.

Thanks

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers