Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753955AbbG2RFZ (ORCPT ); Wed, 29 Jul 2015 13:05:25 -0400 Received: from mail-lb0-f172.google.com ([209.85.217.172]:35248 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751873AbbG2RFV (ORCPT ); Wed, 29 Jul 2015 13:05:21 -0400 MIME-Version: 1.0 In-Reply-To: <20150729163742.GC21625@mail.hallyn.com> References: <1437732285-11524-1-git-send-email-l.pawelczyk@samsung.com> <1437732285-11524-12-git-send-email-l.pawelczyk@samsung.com> <20150729152550.GC19285@mail.hallyn.com> <20150729163742.GC21625@mail.hallyn.com> Date: Wed, 29 Jul 2015 19:05:19 +0200 Message-ID: Subject: Re: [PATCH v3 11/11] smack: documentation for the Smack namespace From: Lukasz Pawelczyk To: "Serge E. Hallyn" Cc: Lukasz Pawelczyk , "Eric W. Biederman" , Al Viro , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , David Howells , Eric Dumazet , Eric Paris , Fabian Frederick , Greg KH , James Morris , Jiri Slaby , Joe Perches , John Johansen , Jonathan Corbet , Kees Cook , Mauro Carvalho Chehab , NeilBrown , Oleg Nesterov , Paul Moore , Stephen Smalley , Tetsuo Handa , Zefan Li , linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2628 Lines: 63 Just a clarification, from my previous email: > 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. What I meant is: "There is NO way that this will not involve host admin." Typo, sorry. On Wed, Jul 29, 2015 at 6:37 PM, Serge E. Hallyn wrote: > 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. This by itself like I said would theoretically be possible (without the "no admin intervention" and "modifying rules" parts). You mark the container prefixed with something, let's say with "C1". Now any new label you create inside a namespace will get automatic (implicit) mapping: C1-label -> label Casey disliked the idea for these reasons (there was actually more then one as I remember now): 1. What I said previously about special meaning for labels. The real host label C1-label has a meaning now. 2. Labels have a specific max length. By prefixing them we reduce that length, and it is pressumed to be true in several parts of the code. 3. This mechanic allows users to import labels, and as Smack doesn't free or reuse them this is potentially DOS surface. Granted this is technical limitation only that could be remedied at some point, but for now the assumption that labels are not destroyed is taken advantage of in several parts of the code to simplify the implementation of Smack itself. (Mappings and mapped label structures are freed with the end of life of user namespace). > One hurdle to overcome there, of course, is how to reproduce that > mapping the next time we create this container. The name of the real label would hold the info (C1-label). > Anyway, if this patchset is simply about making smack work in user_ns > at all, I'll reread with that in mind :) Would appreciate. Thanks, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/