Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752221AbdGMMTi (ORCPT ); Thu, 13 Jul 2017 08:19:38 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53311 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751145AbdGMMTf (ORCPT ); Thu, 13 Jul 2017 08:19:35 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Theodore Ts'o" Cc: Stefan Berger , "Serge E. Hallyn" , 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-1-git-send-email-stefanb@linux.vnet.ibm.com> <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> Date: Thu, 13 Jul 2017 07:11:36 -0500 In-Reply-To: <20170713011554.xwmrgkzfwnibvgcu@thunk.org> (Theodore Ts'o's message of "Wed, 12 Jul 2017 21:15:54 -0400") Message-ID: <87y3rscz9j.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dVd5c-0003Y8-LZ;;;mid=<87y3rscz9j.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/AK/RU1YURIqJNFFWXu12LPptDNO/kGJM= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa03 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Theodore Ts'o X-Spam-Relay-Country: X-Spam-Timing: total 1553 ms - load_scoreonly_sql: 0.08 (0.0%), signal_user_changed: 7 (0.5%), b_tie_ro: 5 (0.3%), parse: 2.1 (0.1%), extract_message_metadata: 7 (0.5%), get_uri_detail_list: 2.5 (0.2%), tests_pri_-1000: 12 (0.8%), tests_pri_-950: 3.1 (0.2%), tests_pri_-900: 2.3 (0.1%), tests_pri_-400: 36 (2.3%), check_bayes: 33 (2.1%), b_tokenize: 13 (0.8%), b_tok_get_all: 9 (0.6%), b_comp_prob: 5 (0.3%), b_tok_touch_all: 2.7 (0.2%), b_finish: 0.97 (0.1%), tests_pri_0: 1443 (92.9%), check_dkim_signature: 1.32 (0.1%), check_dkim_adsp: 5 (0.4%), tests_pri_500: 12 (0.8%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1498 Lines: 37 Theodore Ts'o writes: > I'm really confused what problem that is trying to be solved, here, > but it **feels** really, really wrong. > > Why do we need to store all of this state on a per-file basis, instead > of some kind of per-file system or per-container data structure? > > And how many of these security.foo@uid=bar xattrs do you expect there > to be? How many "foo", and how many "bar"? > > Maybe I missed the full write up, in which case please send me a link > to the full writeup --- ideally in the form of a design doc that > explains the problem statement, gives some examples of how it's going > to be used, what were the other alternatives that were considered, and > why they were rejected, etc. The concise summary: Today we have the xattr security.capable that holds a set of capabilities that an application gains when executed. AKA setuid root exec without actually being setuid root. User namespaces have the concept of capabilities that are not global but are limited to their user namespace. We do not currently have filesystem support for this concept. We currently have two proposals on the table. One is to bump the revision number of security.capable and add more information in that xattr. The other is to use a sligthly different capability name. We are currently evaluating between the two proposals. Given that it appears the IMA xattrs will want similar treatment coming up with a good pattern to follow is part of the analysis here. Eric