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

[Tom Weber]

Am Mittwoch, den 06.08.2014, 17:47 +0000 schrieb 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.

They should do what I told them - use the apparmor profile i specified,
not rely on a silly security check and ignore it completely.

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

No. Software should help me to do things the right way, not get into my
way if i prefer to do things the author didn't think of.

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

And I'm trying to explain you why you can't and shouldn't check other
components this way.

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

Your package is called lxc - it's not called apparmor. The defaults are
what the distribution packages together.
lxc itself can't provide secure containers (yet). There is nothing you
can do about this - you can only get lxc's job right.
apparmor itself can help increase security - with or without mount
patching the kernel - but thats out of the scope of lxc to judge on
apparmor.
there might be other ways to work around the mount problem (maybe a
cap_mount patch in the kernel) - and you don't know nothing about these
things.
Yet you imply that either the setup is insecure or that you care that
much about security that everyone thinks the system is secure if they
turn on these switches and the software doesn't complain - both is
wrong.

It's up to the distribution to pull the various components together and
create a sane and safe default solution for the regular ubuntu, debian,
redhat whatever user. All you can do is provide sane default profiles
for the various parts like apparmor or selinux or whatever. But it's
entirely the distribution's job to verify and implement whatever makes
sense.
A check like you do for that mount feature - and actions based on it -
just lead into some kind of dependency hell where one or a distribution
can't easily build the system the way they want.

And 'security' checks that give different results on different
platforms/setups even though the real security is the same are just
wrong.

If the someone chooses to install it's own stuff and packages it's
always up to them to take care about a secure setup - you're lost, you
can't check, you can't enforce or help with checks that say nothing
because you simply don't know anything of the intentions or setup.

Linux systems are build from many packages. Each should get it's own
stuff right. It's the system builder / distributions job to deliver a
secure system with sane defaults - not that of a package.

Does rsync check for misconfigured/insecure/missing ssh
settings/features when relying on ssh as transport for filetransfers?
No.

What's next? A mail reader that tells me that my X11 setup is insecure
for whatever reason and wont start because someone might steal my
password? 

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

You'll just end up with howtos and forum posts like
Q) my container wont start
A) try putting lxc.apparmor.require_mount = 0 in your container config

and people will do so by default because lxc + apparmor won't work on
more than 50% of the systems otherwise. There goes your sane default.
And it will be argued that turning this check off will make the
containers more secure because it will allow them to make use of
apparmor - maybe not for mount protection, but at least for file access
protection.

I really would prefer proper logging and debugging output from lxc over
all that apparmor fiddling you try to think of.
Like I said, the WARN() messages of your patch don't appear anywhere on
my system.
lxc not giving me any feedback about it's refusal to activate the
apparmor profile I configured did cost me hours to figure the problem.
IMHO these things are way more important to fix than to implement
switches to test and judge other components of the system.

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

huh? don't see what you wanna tell me?
apparmor doesn't lie about anything. It tells me that it can't enforce
the mount rules - but everything else works. and apparmor is the only
thing about to judge on this. 

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

the defaults are the job of the distribution. You can't enforce, judge
or rely on defaults if people start installing or compiling their own
stuff. And people that do so are usually supposed to know what they do.


Regards,
  Tom