From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Fri, 14 Jul 2017 15:43:46 -0400 Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> References: <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> <1500058090.3583.28.camel@linux.vnet.ibm.com> <20170714192909.zoxnlm32nrxguqao@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170714192909.zoxnlm32nrxguqao-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Theodore Ts'o Cc: Mimi Zohar , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Eric W. Biederman" , casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org, lkp-JC7UmRfGjtg@public.gmane.org List-Id: containers.vger.kernel.org T24gRnJpLCAyMDE3LTA3LTE0IGF0IDE1OjI5IC0wNDAwLCBUaGVvZG9yZSBUcydvIHdyb3RlOgo+ IE9uIEZyaSwgSnVsIDE0LCAyMDE3IGF0IDAyOjQ4OjEwUE0gLTA0MDAsIE1pbWkgWm9oYXIgd3Jv dGU6Cj4gPiAKPiA+IElmIEknbSB1bmRlcnN0YW5kaW5nIHRoZSBkaXNjdXNzaW9uIGNvcnJlY3Rs eSwgdGhpcyBpc24ndCBhbiBpc3N1ZSBmb3IKPiA+IGxheWVyZWQgY29weSBvbiB3cml0ZSBmaWxl c3lzdGVtcywgYXMgZWFjaCBmcyBsYXllciBjb3VsZCBoYXZlIGl0J3MKPiA+IG93biBzZXQgb2Yg eGF0dHJzLiDCoFRoZSB1bmRlcmx5aW5nIGFuZCBsYXllcmVkIHhhdHRycyBzaG91bGQgYmUgYWJs ZQo+ID4gdG8gY28tZXhpc3QuIMKgVXNlIHRoZSBsYXllcmVkIHhhdHRyIGlmIGl0IGV4aXN0cywg YnV0IGZhbGwgYmFjayB0bwo+ID4gdXNpbmcgdGhlIHVuZGVybHlpbmcgeGF0dHIgaWYgaXQgZG9l c24ndC4KPiAKPiBOb3RlIHRoYXQgdGhpcyBhc3N1bWVzIHRoYXQgaXQgaXMgcG9zc2libGUgdG8g ImNvcHkgdXAiIHRoZSB4YXR0cnMKPiB3aXRob3V0IG5lY2Vzc2FyaWx5ICJjb3B5aW5nIHVwIiBh bGwgb2YgdGhlIGRhdGEgYmxvY2tzLiAgVGhpcyBtaWdodAo+IGJlIHRydWUgZm9yIHNvbWUgbGF5 ZXJzLCBidXQgSSBkb24ndCBiZWxpZXZlIGl0IGlzIGN1cnJlbnRseSB0cnVlIGZvcgo+IG92ZXJs YXlmcywgZm9yIGV4YW1wbGUuCgpPaywgc28gZm9yIHRoZSB1c2UgY2FzZSBzY25lYXJpbyB3aGVy ZSB0aGUgY29udGFpbmVyIG93bmVyIGlzIHdpbGxpbmcKdG8gdXNlIHRoZSBwdWJsaWMga2V5IGRp c3RyaWJ1dGVkIHdpdGggdGhlIGZpbGVzLCB0aGVuIG9ubHkgdGhvc2UKZmlsZXMgdGhhdCBhcmUg bmV3IG9yIG1vZGlmaWVkIGluIHRoZSBvdmVybGF5IHdvdWxkIG5lZWQgdG8gYmUgc2lnbmVkCndp dGggYSBrZXkgbG9jYWwgdG8gdGhlIG92ZXJsYXkuIMKgSW4gdGhlIHdvcnN0IGNhc2Ugc2NlbmFy aW8sIHdoZXJlCnRoZSBjb250YWluZXIgb3duZXIgaXMgb25seSB3aWxsaW5nIHRvIHRydXN0IHRo ZWlyIG93biBwdWJsaWMga2V5LCBJCmd1ZXNzIHdlIGNhbiBsaXZlIHdpdGggaGF2aW5nIHRvIGNv cHkgdXAgdGhlIGZpbGVzLgoKTWltaQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KQ29udGFpbmVycyBtYWlsaW5nIGxpc3QKQ29udGFpbmVyc0BsaXN0cy5s aW51eC1mb3VuZGF0aW9uLm9yZwpodHRwczovL2xpc3RzLmxpbnV4Zm91bmRhdGlvbi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb250YWluZXJz From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Fri, 14 Jul 2017 15:43:46 -0400 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org> References: <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> <1500058090.3583.28.camel@linux.vnet.ibm.com> <20170714192909.zoxnlm32nrxguqao@thunk.org> Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote: > On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote: > > > > If I'm understanding the discussion correctly, this isn't an issue for > > layered copy on write filesystems, as each fs layer could have it's > > own set of xattrs. ?The underlying and layered xattrs should be able > > to co-exist. ?Use the layered xattr if it exists, but fall back to > > using the underlying xattr if it doesn't. > > Note that this assumes that it is possible to "copy up" the xattrs > without necessarily "copying up" all of the data blocks. This might > be true for some layers, but I don't believe it is currently true for > overlayfs, for example. Ok, so for the use case scneario where the container owner is willing to use the public key distributed with the files, then only those files that are new or modified in the overlay would need to be signed with a key local to the overlay. ?In the worst case scenario, where the container owner is only willing to trust their own public key, I guess we can live with having to copy up the files. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============3387449669300812548==" MIME-Version: 1.0 From: Mimi Zohar To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Fri, 14 Jul 2017 15:43:46 -0400 Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org> List-Id: --===============3387449669300812548== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote: > On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote: > > = > > If I'm understanding the discussion correctly, this isn't an issue for > > layered copy on write filesystems, as each fs layer could have it's > > own set of xattrs. =C2=A0The underlying and layered xattrs should be ab= le > > to co-exist. =C2=A0Use the layered xattr if it exists, but fall back to > > using the underlying xattr if it doesn't. > = > Note that this assumes that it is possible to "copy up" the xattrs > without necessarily "copying up" all of the data blocks. This might > be true for some layers, but I don't believe it is currently true for > overlayfs, for example. Ok, so for the use case scneario where the container owner is willing to use the public key distributed with the files, then only those files that are new or modified in the overlay would need to be signed with a key local to the overlay. =C2=A0In the worst case scenario, where the container owner is only willing to trust their own public key, I guess we can live with having to copy up the files. Mimi --===============3387449669300812548==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751205AbdGNToE (ORCPT ); Fri, 14 Jul 2017 15:44:04 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37222 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751061AbdGNToB (ORCPT ); Fri, 14 Jul 2017 15:44:01 -0400 Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces From: Mimi Zohar To: "Theodore Ts'o" Cc: "Serge E. Hallyn" , Stefan Berger , Mimi Zohar , "Eric W. Biederman" , 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 Date: Fri, 14 Jul 2017 15:43:46 -0400 In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org> References: <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> <1500058090.3583.28.camel@linux.vnet.ibm.com> <20170714192909.zoxnlm32nrxguqao@thunk.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17071419-0044-0000-0000-0000027FC74B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071419-0045-0000-0000-000007107CE2 Message-Id: <1500061426.3583.65.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-14_13:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707140312 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote: > On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote: > > > > If I'm understanding the discussion correctly, this isn't an issue for > > layered copy on write filesystems, as each fs layer could have it's > > own set of xattrs.  The underlying and layered xattrs should be able > > to co-exist.  Use the layered xattr if it exists, but fall back to > > using the underlying xattr if it doesn't. > > Note that this assumes that it is possible to "copy up" the xattrs > without necessarily "copying up" all of the data blocks. This might > be true for some layers, but I don't believe it is currently true for > overlayfs, for example. Ok, so for the use case scneario where the container owner is willing to use the public key distributed with the files, then only those files that are new or modified in the overlay would need to be signed with a key local to the overlay.  In the worst case scenario, where the container owner is only willing to trust their own public key, I guess we can live with having to copy up the files. Mimi