lxc-start is unconfined but has a profile defined

Thanks for reporting this bug. I can't reproduce this on a
stock saucy system. How and when was that container created
and started? Was it auto-started (since it's pid 471)? If
you stop and restart the container, does that continue to be
the case? Is it possible you had done unloaded all profiles
and restarted apparmor while the container was running?

Lxc doesn't do anything in particular to enter the lxc-start
profile, it just gets entered into it by the pathname. Apart
from explicitly entering the unconfined domain (which is only
done by the init process, if you have

 lxc.aa_profile = unconfined

inthe container configuration file, right before executing
/sbin/init) So I'm not sure what lxc could have done to get
into this state, but I sure hope we can get to the bottom of it.

 priority: high
 status: incomplete

As mentioned, this was is on an Ubuntu Touch system and it happens on boot. It is still the case as of today. I don't know much about the container flip on Touch devices, but right now, the apparmor profile is not in effect on these systems. I can confirm this on the Nexus 7 (grouper) and Nexus 4 (mako).

Unfortunately, today someone (vila) reported the following denial during a test run:
/var/log/syslog: Oct 8 09:16:26 saucy-i386-20131008-0916 dbus[499]: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="Hello" mask="send" name="org.freedesktop.DBus" pid=634 profile="lxc-container-default" peer_profile="lxc-container-default" info="Permission denied"

I think this indicates a race condition where lxc somehow won the race and the profile was in effect, but the profile itself is missing needed rules because no one has actually seen/noticed this condition due to this bug.

Ah, so this is a bug in the lxc-android-config package. Its upstart job, which does an lxc-start, needs to wait for the lxc upstart job to complete, since lxc is the one to load the apparmor profiles.

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

Or it can manually load the lxc apparmor profiles the same way /etc/lxc/lxc.conf does.

@Serge: I encounter the issue in

http://10.97.0.1:8080/job/autopilot-saucy-daily_release/label=autopilot-intel/2465/console

which runs on intel. I will try to reproduce locally (this happened in the ci lab).

The LXC container on touch has always been lxc.aa_profile=unconfined so whether apparmor is ready or not shouldn't matter since it's configured not to use it.

If we did want apparmor to protect the container, then we'd indeed have a race at the moment, but since we don't, I'm pretty confused as to how you ended up with the reject.

Here is my understanding:

1. so long as a container has a profile specified, then if the apparmor policies have not been loaded, the container start will fail.

2. In the lxc-android-config case, the container has lxc.aa_profile = unconfined. Therefore it is possible for lxc-start (which normally has its own somewhat flexible profile) to run unconfined, but there will be no difference for the actual container.

We consider the container to be the untrustworthy thing. per (1) if it is supposed to run in a profile and that profile is not loaded, the start will correctly fail. However lxc-start itself may run unconfined. I'm open to suggestions for how to enforce that it should be confined and is in fact running unconfined. But I can't think of any. The user could, and sometimes does, purposely run it unconfined, and I don't want to break that.

I'd like to (after saucy) break /etc/init/lxc.conf into /etc/init/lxc-aa.conf and /etc/init/lxc-autostart.conf. lxc-net.conf would start on runlevel 2345, lxc-autostart.conf would start on started lxc-net.conf and lxc-aa.conf. lxc-aa.conf would start on filesystem, to load the apparmor policies as early as possible. We could then also have lxc-start fail if lxc-aa.conf is not started. The way to disable apparmor, in that case, would be to set LXC_AA=false in /etc/default/lxc. That way lxc-aa.conf could still start even if aa is disabled for lxc.

I had been considering splitting the lxc apparmor profile loading to its own upstart job so it would happen sooner, but that will only make the container start weirdly due to lxc-net not having started. What we need is a way for lxc-start to know that it shouldn't run yet.

I propose we add a 'lxc.wait_on_file = /run/lxc/ready' to the container config format. We add that entry to the /etc/lxc/lxc.conf in ubuntu, and have /etc/init/lxc.conf create /run/lxc/ready when all is set. lxc-start will simply wait until the condition is satisfied to actually start the container (logging a message that it is doing so), rather than failing to start.

This bug was fixed in the package lxc - 1.0.0~alpha2-0ubuntu5

---------------
lxc (1.0.0~alpha2-0ubuntu5) trusty; urgency=low

  [ Serge Hallyn]
  * debian/rules and debian/lxc.postinst: set /var/lib/lxc and /var/cache/lxc
    to be perms 700. That prevents unprivileged users from running setuid-root
    applications. Install that way by default, and for any previous versions,
    update the permissions. After this version, respect the user's choice.
    (LP: #1244635)

  [ Stéphane Graber ]
  * Allow lxc.conf to start even if LXC_AUTO=false so that other jobs
    can depend on it. Also make sure we always load our apparmor profiles.
    (LP: #1227937)
 -- Stephane Graber <email address hidden> Tue, 29 Oct 2013 12:15:21 -0400