Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752874AbdGMTOo (ORCPT <rfc822;w@1wt.eu>);
        Thu, 13 Jul 2017 15:14:44 -0400
Received: from imap.thunk.org ([74.207.234.97]:47344 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752517AbdGMTOl (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 13 Jul 2017 15:14:41 -0400
Date: Thu, 13 Jul 2017 15:14:29 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        containers@lists.linux-foundation.org, lkp@01.org,
        linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com,
        tycho@docker.com, James.Bottomley@HansenPartnership.com,
        vgoyal@redhat.com, christian.brauner@mailbox.org, amir73il@gmail.com,
        linux-security-module@vger.kernel.org, casey@schaufler-ca.com
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Message-ID: <20170713191429.vfaetqscxd7hniwq@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Stefan Berger <stefanb@linux.vnet.ibm.com>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        containers@lists.linux-foundation.org, lkp@01.org,
        linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com,
        tycho@docker.com, James.Bottomley@HansenPartnership.com,
        vgoyal@redhat.com, christian.brauner@mailbox.org,
        amir73il@gmail.com, linux-security-module@vger.kernel.org,
        casey@schaufler-ca.com
References: <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com>
 <87mv89iy7q.fsf@xmission.com>
 <20170712170346.GA17974@mail.hallyn.com>
 <877ezdgsey.fsf@xmission.com>
 <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com>
 <20170713011554.xwmrgkzfwnibvgcu@thunk.org>
 <87y3rscz9j.fsf@xmission.com>
 <20170713164012.brj2flnkaaks2oci@thunk.org>
 <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce@linux.vnet.ibm.com>
 <8760ew9qyp.fsf@xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8760ew9qyp.fsf@xmission.com>
User-Agent: NeoMutt/20170306 (1.8.0)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2608
Lines: 74

On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
> 
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.

That's why I've been pushing here.  If people try to do

   security.capable@uid=1000
   security.capable@uid=2000
   security.capable@uid=3000
   security.capable@uid=4000
   security.capable@uid=5000
   security.capable@uid=6000
   security.capable@uid=7000
   security.capable@uid=8000
   security.capable@uid=9000
         .
	 .
	 .

... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.

So maybe we are better off if we define an xattr

   security.capable@guest-container

... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.

Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.

E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.

I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.


The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:

   security.ima@uid=1000
   security.ima@uid=2000
   security.ima@uid=3000
   security.ima@uid=4000
   security.ima@uid=5000
   security.ima@uid=6000
   security.ima@uid=7000
   security.ima@uid=8000
   security.ima@uid=9000
	.
	.
	.

Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature.  Now let's assume there are 10,000
containers, each of which needs a separate RSA signature.  This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.

					- Ted