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

[Serge Hallyn]

Quoting Tom Weber (l_lxc-users at mail2news.4t2.com):
> 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

Yeah that shouldn't be the case, they should fail to start.

> 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

But it should!  It just should be a minimal burden.

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

I don't want to limit you.  I want to provide you a configurable option
to do what you want.  We're just still discussing what that should look
like.

But you come back to my earlier point nicely - on a mac you wouldn't
have to option to recompile when they've failed to provide you the
option.  I fully agree you shouldn't have to recompile.  I'm just
saying that until we work this out, you have that option.

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

Here I think you are missing the point.  I don't want to guarantee that
your container is safe.  I want to guarantee that when you use the
defaults, you are getting a certain level of safety.  If you don't use
the defaults, you should know what you're doing of course.

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

You're arguing with my choice of terms.  Offer better terms then :)  I
agree safe is probably misleading.  We want something connoting
"do not start if not fully available in the kernel".

Perhaps it should be

lxc.apparmor.require_mount = [0|1], with default being 1?

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

Likewise there are probably scores of kernel exploits in the lastest
kernel.  That doesn't mean that if selinux isn't enabled sestatus should
lie to you and say your policy is enforcing.

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

Again I'm talking about the defaults.

> 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
> 
> 
> 
> 
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users