linux-kernel - Re: [PATCH v3 11/11] smack: documentation for the Smack namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACL4Mm-UXodv+GcEbwVVoiDYUqa39YW3+RTnS7O61cUj8Pk6Og@mail.gmail.com>
Date:	Wed, 29 Jul 2015 19:05:19 +0200
From:	Lukasz Pawelczyk <havner@...il.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Lukasz Pawelczyk <l.pawelczyk@...sung.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Arnd Bergmann <arnd@...db.de>,
	Casey Schaufler <casey@...aufler-ca.com>,
	David Howells <dhowells@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Eric Paris <eparis@...isplace.org>,
	Fabian Frederick <fabf@...net.be>,
	Greg KH <gregkh@...uxfoundation.org>,
	James Morris <james.l.morris@...cle.com>,
	Jiri Slaby <jslaby@...e.com>, Joe Perches <joe@...ches.com>,
	John Johansen <john.johansen@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Kees Cook <keescook@...omium.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	NeilBrown <neilb@...e.de>, Oleg Nesterov <oleg@...hat.com>,
	Paul Moore <paul@...l-moore.com>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Zefan Li <lizefan@...wei.com>, linux-doc@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH v3 11/11] smack: documentation for the Smack namespace

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 <serge@...lyn.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/