On Wed, Jul 29, 2015 at 06:13:59PM +0200, Lukasz Pawelczyk wrote: > Appologise for sending my previous email in HTML, this email address > was never meant to be used with lists. I resend in plain text. > > On Wed, Jul 29, 2015 at 5:25 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > > >> +Enabling Smack related capabilities (CAP_MAC_ADMIN and > >> +CAP_MAC_OVERRIDE) is main goal of Smack namespace, so it can work > >> +properly in the container. And those capabilities do work to some > >> +extent. In several places where capabilities are checked compatibility > >> +with Smack namespace has been introduced. Capabilities are of course > >> +limited to operate only on mapped labels. > >> + > >> +CAP_MAC_OVERRIDE works fully, will allow you to ignore Smack access > >> +rules, but only between objects that have labels mapped. So in the > >> +example above having this CAP will allow e.g. label2 to write to > >> +label1, but will not allow any access to label3. > > > > (Sorry it took me this long to get to reading, and thanks for working > > on this) > > > > Oh my. All this is not at all what I'd expected :) > > > > Is there rationale for these decisions? Hm, I guess it really is > > following the user_ns design, but the huge difference is that the > > user_ns is partitioning an already-enumerated set of kuids. The > > smack labels are inherently different. > > There is a big rationale for this. This is not to make Smack limit how > namespace can be created (this can be done separately, no conflict > here). This is to make Smack work at all inside a namespace. Please > note that contrary to SELinux and AppArmor Smack needs CAP_MAC_ADMIN > for it to operate on a normal basis. There is no rule for changing > labels. CAP_MAC_ADMIN is always required for this. And you cannot > unlock and give this capability just like that to anyone. Like in > every namespace you need a level of abstraction to allow an > unprivileged namespace to administer something. Hm, ok - it's been a few years since I used smack, so I'll go back and re-read the Documentation file first, then the doc patch and this email again. > > In containers, something we'd really like to be able to do is: > > > > Create a new container. Just run it as label 'c1'. Inside the > > container, let the admin install mysql from a package which assigns > > type 'mysqld', protecting the rest of the container from mysql. > > Without the host admin doing anything. > > > > Normally the way I think of implementing something like this would be > > to allow the host to say "c1 is to be namespaceable." Then on a userns > > unshare, if the task is in c1, it gets transitioned into the ns. Then the > > container sees c1 as _ (or whatever). It can create 'mysql' which is > > actually 'c1.mysql' on the host, and it can create and override rules > > to c1.*. > > Few things here. > 1. Such an extension with using prefixes (with two exceptions, see > below) could be added to my patches. I even planned to do so (make a > prefix for a container and assign it a group of labels, this doesn't > conflict with arbitrary mapping). But this was refused by Casey on a > basis that by Smack defintion labels have no meaning. So no prefixes. Ok, I'm hoping to discuss this with Casey at LSS. I assume there will be reasons why what I want is simply not possible, but I'd like to give it a shot :) One way around this might be to let the host admin say: create smack labels c1_a1..c1_aN. Map them into the container in a way such that they have no name in the container yet. Now when container admin says "create mysql_t", so long as there is a not-yet-named mapped label, c1-aM, it gets mapped to the new name. One hurdle to overcome there, of course, is how to reproduce that mapping the next time we create this container. Anyway, if this patchset is simply about making smack work in user_ns at all, I'll reread with that in mind :) > 2. (expcetion #1) Changing any rules in a container has been deemed > too insecure at this point. > 3. (expcetion #2) About the: "Without the host admin doing anything.". > With this namespace you delegate part of CAP_MAC_ADMIN privilege to an > unprivileged user (as with any other namespace). There is now way that > this will not involve host admin. The way you described it you allow > an unprivileged process to change its own label and change labels on a > filesystem. This is simply against Smack rules and completely > insecure. Even with user_ns if you map several UID you need admin > intervention. > > > > Also, allowing CAP_MAC_OVERRIDE in this way seems overly dangerous. > > If there were rules defined by the container, then I'd expect those to > > be overrideable - but not all rules pertaining to all labels mapped > > into the container. But I guess based on your envisioned usage (where > > I assume 'label1' is meant to *only* be used for that container) it > > might be ok. > > CAP_MAC_OVERRIDE is only possible for labels that the admin explicitly > mapped. So it's up to him to decide what is dangerous or not. It can > only map labels that are not used outside of the container if it > wishes to. But the user himself will not be able to explot that > without permission from the admin. > > So sorry this is not what you expected, but it seems that what you > expected is simply not feasible. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
