Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751073AbdGNSZP (ORCPT ); Fri, 14 Jul 2017 14:25:15 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:55952 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799AbdGNSZM (ORCPT ); Fri, 14 Jul 2017 14:25:12 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Stefan Berger , Mimi Zohar , "Theodore Ts'o" , containers@lists.linux-foundation.org, lkp@01.org, linux-kernel@vger.kernel.org, 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: <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <87k23cb6os.fsf@xmission.com> <847ccb2a-30c0-a94c-df6f-091c8901eaa0@linux.vnet.ibm.com> <87bmoo8bxb.fsf@xmission.com> <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com> <87h8yf7szd.fsf@xmission.com> <65dbe654-0d99-03fa-c838-5a726b462826@linux.vnet.ibm.com> <20170714133437.GA16737@mail.hallyn.com> <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> <20170714173556.GA19669@mail.hallyn.com> Date: Fri, 14 Jul 2017 13:17:08 -0500 In-Reply-To: <20170714173556.GA19669@mail.hallyn.com> (Serge E. Hallyn's message of "Fri, 14 Jul 2017 12:35:56 -0500") Message-ID: <8760euyjbv.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=1dW5Gw-0001zX-S1;;;mid=<8760euyjbv.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/rBbykH/n2coPbYh1JUG3oUIQf2ndPaH8= 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.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 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 * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Timing: total 5855 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.6 (0.1%), b_tie_ro: 2.4 (0.0%), parse: 1.64 (0.0%), extract_message_metadata: 28 (0.5%), get_uri_detail_list: 6 (0.1%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.33 (0.0%), tests_pri_-900: 1.10 (0.0%), tests_pri_-400: 30 (0.5%), check_bayes: 29 (0.5%), b_tokenize: 11 (0.2%), b_tok_get_all: 10 (0.2%), b_comp_prob: 3.2 (0.1%), b_tok_touch_all: 3.2 (0.1%), b_finish: 0.59 (0.0%), tests_pri_0: 451 (7.7%), check_dkim_signature: 0.57 (0.0%), check_dkim_adsp: 54 (0.9%), tests_pri_500: 5326 (91.0%), poll_dns_idle: 5318 (90.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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4068 Lines: 99 "Serge E. Hallyn" writes: > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >> >>>Stefan Berger writes: >> >>> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: >> >>>> >> >>>>>My big question right now is can you implement Ted's suggested >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ? >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. >> >>>> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? >> >>>> >> >>>The latter. >> >>That case would prevent a container user from overriding the xattr >> >>on the host. Is that what we want? For limiting the number of xattrs >> >Not really. If the file is owned by a uid mapped into the container, >> >then the container root can chown the file which will clear the file >> >capability, after which he can set a new one. If the file is not >> >owned by a uid mapped into the container, then container root could >> >not set a filecap anyway. >> >> Let's say I installed a container where all files are signed and >> thus have security.ima. Now for some reason I want to re-sign some >> or all files inside that container. How would I do that ? Would I >> need to get rid of security.ima first, possibly by copying each >> file, deleting the original file, and renaming the copied file to >> the original name, or should I just be able to write out a new >> signature, thus creating security.ima@uid=1000 besides the >> security.ima ? >> >> Stefan > > Hi Mimi, > > what do you think makes most sense for IMA? I am going to give my two cents since I have been thinking about this. First I think this entire scheme plays hobs with the security.evm attribute as security.evm needs to know the names of the xattrs to protect. I forget which attributes has a hash and what has a message athentication code. If there is an attribute with a simple file hash I think it only make sense for the kernel to touch it, and I don't see any sense in having multiples. If there is an attribute with a message authentication code (roughly a signed hash) it makes sense to have that to be tied to the kernel key ring that controlls the keys. (Which probably means a per user namespace thing at some point). But again pretty untouchable otherwise. Which brings us to the semantic question of would it be nice to have stacked IMA/EVM on the same file. I really don't think we do. I think allowing multiple keys for different part of trusting files is easy enough that we should have no need to fight over which keys do which. Looking at integrity.h I see signature_v2_hdr that has a keyid. Any use case I can think of for distributing a distribution image with ima/evm xattrs will need to use asymmetric keys aka public/private keypairs so that the originator of the content does not give away their private keys. Given that usefully we are talking about content that should be connected to keys in one way or another I don't believe it even makes sense at this point to attempt to use uids for dealing with ima and evm content. Further looking Serge's previous patch is 300 lines of code Setfan's patch that provides the possibility of code resuse is 500 lines of code. Increasingly it is looking to me that code reuse rather than concept reuse is a false economy. The code does not get smaller. The semantic differences make it problematic. Possibly to the problematic to the point where significant pieces may not be reused. The format breaks assumptions for other parts of the code like security.evm. The format by multiple names instead of a single attribute requires more disk access so is less efficient. In short I am seeing more code that runs slower and is harder to maintain. Please point out where I am wrong. Eric