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

[Tom Weber]

Am Mittwoch, den 06.08.2014, 14:51 +0000 schrieb 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.'

none of these would be usefull if you don't also check for a correctly
configured apparmor profile.
So you tell me that i can always recompile if i don't want your security
checks, but everyone can render the security you check for completely
useless by editing an apparmor profile - and none of your checks would
even notify.

> > 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

I agree that the default setting should be safe. 3 days ago your default
on a debian or vanilla kernel built system was to _silently_ ignore
apparmor _completely_ - not even the slightest protection through
apparmor was possible _at all_! I wonder how many people run lxc and
think that apparmor is active while it isn't at all due to this.

But it should not be a bourdon to me to do things the way I want, even
if I decide to have an insecure setup. I'd buy/use Macs if i'd want the
developer to limit me to the things he thinks I should be allowed to do.

> lxc.apparmor = [safe|unsafe|off]

that sounds nice, but the problem is that you can't say anything about
apparmor security for a container if you don't check the apparmor
profile for correctness. And thats out of the scope for lxc.

so people will turn on lxc.apparmor = safe.
lxc won't start and complain about security and apparmor.
so they'll try with lxc.apparmor = unsafe and it will start.
now people will start messing up apparmor profiles until they figure
that they need a kernel with aa-mount support.
they turn on lxc.apparmor = safe and the aa profiles are still messed
up.
but lxc won't complain about security anymore and they'll end up feeling
safe with a messed up container.
you're giving a false sense of security here.

Or think about someone who creates (maybe by mistake) and uses an all
allow (or partly insecure) apparmor profile.
lxc.apparmor = safe would spit in his face on a debian system
lxc.apparmor = safe wouldn't complain at all on an ubuntu system
that makes no sense for me.

if you implement a 'safe' flag that's supposed to prevent an unsafe
container from starting, you better implement it correctly or not at
all. 
It's like a button labeled: make this container apparmor safe. people
push it and expect the container to be apparmor safe while it doesn't
need to be.

> 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?

basically yes. it could be misconfigured in apparmor as well.
The availability of a feature doesn't tell you if it's used correctly.

> > 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.

dmesg and /proc/kcore? both are readable from inside - in the default
config.

and i was talking about mounting /proc* or /sys* whatever way i want in
lxc.conainer config. You allow me that, but you want to force me on an
apparmor mount patched kernel if i want to use apparmor.

> > 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.

Yes, i have requested apparmor support from lxc. lxc doesn't know
anything about my apparmor profil I requested - _THATS_ my whole point.
Maybe I dont have mount limiting features in the profile I configured
lxc to use. Thats entirely apparmor's business, not lxc.  
Making asumptions in lxc-start what I should/could/would have to
configure in my apparmor profile is wrong. 

If apparmor cannot fullfill what I request in the apparmor profile, it's
up to apparmor to complain about this - and apparmor does so.


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

that would help indeed.
there could as well be other ways (maybe kernel patches) far outside the
scope of apparmor to solve that mount problem - and again, your check
for that feature wouldn't do no good.

> > 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.

Your default setup can be designed to be safe. 
But you cant design them to be safe in every possible allowed setup - It
just happened that you forbid me my personal (and most likely secure)
setup by your security checks - whereas, otoh you do nothing to prevent
people from running insecure setups.


> If you simply want to disable apparmor, you can always set
> 
> lxc.aa_profile = unconfined.

I do want to use lxc containers the way I (as an experienced admin)
want. I don't want lxc to forcefeed me some kind of security. 
I do want to be able to run containers, with or without apparmor
protection (that means with or without apparmor mount protection), with
or without cap_sys_admin in any imaginable combination.

> 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.

I guess so :) If I only had more time and wasn't out of coding for like
20years.
BTW: does lxc-start start a container even if any of the features
lxc-checkconfig checks for are missing? Could such a container be
secure? :)

Regards,
  Tom