[lxc-users] lxc-start fails at apparmor detection

[Serge Hallyn]

Quoting Tom Weber (l_lxc-users at mail2news.4t2.com):
> Am Dienstag, den 05.08.2014, 23:34 +0000 schrieb Serge Hallyn:
> > Quoting Tom Weber (l_lxc-users at mail2news.4t2.com):
> >  
> > > The patch works in the regard that the container starts and the apparmor
> > > profile is set. 
> > > But I can't find the Warning message anywhere (tried lxc-start -n webv1
> > > -d -l DEBUG) - but maybe thats a more general problem. Oh, and there is
> > > a typo: Apparmor ount
> > > 
> > > My opinion as an admin is that this check isn't needed in lxc itself.
> > > Apparmor spits a warning during aa lxc-profile loading - sane admins
> > > wouldn't ignore this.
> > 
> > We're not just talking about "sane admins" though.  We're talking about
> > everyday users using containers.  And they're not building their own
> > misconfigured kernels.  It happens, certainly while using the development
> > release, that you get a kernel for which the apparmor set wasn't ready
> > yet and mount restrictions weren't ready.
> > 
> > Maybe the patch should be modified to only allow the container to
> > proceed if cap_sys_admin is being dropped.
> 
> So if I _want_ an insecure container with cap_sys_admin (for whatever
> reason like testing or development - and yes sometimes I might want

Well in the end it's open source and you can comment out two lines and
build your own :)

We could also add a set of security flags to specify what the container
considers required.  So it might include 'selinux must be enabled', and
'mount restrictions in apparmor must be enabled.'

> this!) you'd force me to install an apparmor mount supported kernel
> where i'd comment out the mount rules in the apparmor profile? Just to
> make that thing start?

There are many many more people who might adversely affect their
system by not having that.  The *defaults* should be safe, and the
burden should be on the one who wants to run insecurely to enable
that.  I admit the burden shouldn't necessarily be "rebuild the
package".  I'm liking the idea of security flags.  I think they
merit some more discussion first, to make sure we get an API that'll
continue to be useful.  Hopefully Dwight (cc:d) wlil have some input.
But worst case, we could just make it an explicit

lxc.apparmor = [safe|unsafe|off]

Maybe I'll send a patch for that later today.

It's worth considering also whether there is anything we require from
apparmor for the unprivileged containers.  If there is then we cannot
allow an unprivileged container to set lxc.apparmor = unsafe|off.  The
only thing I can think of is if there happens to be an 0-day in the
handling of some namespaced procfile that results in privilege
escalation...  I'm cc:ing jjohansen for input from him.

> Just because there's a feature in the kernel (and it's nothing else your
> stat does) doesn't mean that the other end of the system that's
> responsible for enforcing/using it does really use it.  This test
> implies security where no security is.

Are you arguing that I shouldn't check whether the feature is
enabled bc it might be buggy and not working anyway?

> I dont think a readable /proc/kcore inside a container or access to
> dmesg is very secure either - as in the default config.
> I could mount proc on /proc_insecure and create whatever /dev/ nodes I

Not from inside the container.

> like anywhere I want and lxc wouldn't warn me about this at all.

Yes, you can configure it however you want.  The difference is that
the kernel not having the mount restrictions support means it has
*incomplete* apparmor support.  You've requested an apparmor profile,
and the kernel cannot completely implement it.

Really the solution to all this is to get the mount restrictions into
the upstream kernel.

> But you wouldn't allow me to start a container if the _kernel_ lacks
> aa-mount support and i don't drop cap_sys_admin? Really?

Yes, because the container was designed a certain way to be safe,
and a piece making up that design is missing.

If you simply want to disable apparmor, you can always set

lxc.aa_profile = unconfined.

> This test belongs in lxc-checkconfig and should print out a big fat
> warning - right now it's not even mentioned there.

Agreed.  Patches welcome.

-serge