Am Mittwoch, den 06.08.2014, 14:51 +0000 schrieb Serge Hallyn: > Quoting Tom Weber ([email protected]): > > Am Dienstag, den 05.08.2014, 23:34 +0000 schrieb Serge Hallyn: > > > Quoting Tom Weber ([email protected]): > > > > > > > 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 _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
