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: Sun, 16 Jul 2017 07:25:59 -0400 Message-ID: <1500204359.3583.126.camel@linux.vnet.ibm.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> <1500060374.3583.57.camel@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: 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: "Eric W. Biederman" Cc: Theodore Ts'o , 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, casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org, lkp-JC7UmRfGjtg@public.gmane.org List-Id: containers.vger.kernel.org T24gRnJpLCAyMDE3LTA3LTE0IGF0IDE5OjAyIC0wNTAwLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90 ZToKPiBNaW1pIFpvaGFyIDx6b2hhckBsaW51eC52bmV0LmlibS5jb20+IHdyaXRlczoKPiAKPiA+ IE9uIEZyaSwgMjAxNy0wNy0xNCBhdCAxMzoxNyAtMDUwMCwgRXJpYyBXLiBCaWVkZXJtYW4gd3Jv dGU6Cj4gPj4gIlNlcmdlIEUuIEhhbGx5biIgPHNlcmdlQGhhbGx5bi5jb20+IHdyaXRlczoKPiA+ PiAKPiA+PiA+IFF1b3RpbmcgU3RlZmFuIEJlcmdlciAoc3RlZmFuYkBsaW51eC52bmV0LmlibS5j b20pOgo+ID4+ID4+IE9uIDA3LzE0LzIwMTcgMDk6MzQgQU0sIFNlcmdlIEUuIEhhbGx5biB3cm90 ZToKPiA+PiA+PiA+UXVvdGluZyBTdGVmYW4gQmVyZ2VyIChzdGVmYW5iQGxpbnV4LnZuZXQuaWJt LmNvbSk6Cj4gPj4gPj4gPj5PbiAwNy8xMy8yMDE3IDA4OjM4IFBNLCBFcmljIFcuIEJpZWRlcm1h biB3cm90ZToKPiA+PiA+PiA+Pj5TdGVmYW4gQmVyZ2VyIDxzdGVmYW5iQGxpbnV4LnZuZXQuaWJt LmNvbT4gd3JpdGVzOgo+ID4+ID4+ID4+Pgo+ID4+ID4+ID4+Pj5PbiAwNy8xMy8yMDE3IDAxOjQ5 IFBNLCBFcmljIFcuIEJpZWRlcm1hbiB3cm90ZToKPiA+PiA+PiA+Pj4+Cj4gPj4gPj4gPj4+Pj5N eSBiaWcgcXVlc3Rpb24gcmlnaHQgbm93IGlzIGNhbiB5b3UgaW1wbGVtZW50IFRlZCdzIHN1Z2dl c3RlZAo+ID4+ID4+ID4+Pj4+cmVzdHJpY3Rpb24uICBPbmx5IG9uZSBzZWN1cml0eS5mb28gb3Ig c2VjdWlydHkuZm9vQC4uLiBhdHRyaWJ1dGUgPwo+ID4+ID4+ID4+Pj5XZSBuZWVkIHRvIHJhdy1s aXN0IHRoZSB4YXR0cnMgYW5kIGRvIHRoZSBjaGVjayBiZWZvcmUgd3JpdGluZyB0aGVtLiBJIGFt IGZhaXJseSBzdXJlIHRoaXMgY2FuIGJlIGRvbmUuCj4gPj4gPj4gPj4+Pgo+ID4+ID4+ID4+Pj5T byBub3cgeW91IHdhbnQgdG8gYWxsb3cgc2VjdXJpdHkuZm9vIGFuZCBvbmUgc2VjdXJpdHkuZm9v QHVpZD08PiBvciBqdXN0IGEgc2luZ2xlIG9uZSBzZWN1cml0eS5mb28oQFtbOnByaW50Ol1dKik/ Cj4gPj4gPj4gPj4+Pgo+ID4+ID4+ID4+PlRoZSBsYXR0ZXIuCj4gPj4gPj4gPj5UaGF0IGNhc2Ug d291bGQgcHJldmVudCBhIGNvbnRhaW5lciB1c2VyIGZyb20gb3ZlcnJpZGluZyB0aGUgeGF0dHIK PiA+PiA+PiA+Pm9uIHRoZSBob3N0LiBJcyB0aGF0IHdoYXQgd2Ugd2FudD8gRm9yIGxpbWl0aW5n IHRoZSBudW1iZXIgb2YgeGF0dHJzCj4gPj4gPj4gPk5vdCByZWFsbHkuICBJZiB0aGUgZmlsZSBp cyBvd25lZCBieSBhIHVpZCBtYXBwZWQgaW50byB0aGUgY29udGFpbmVyLAo+ID4+ID4+ID50aGVu IHRoZSBjb250YWluZXIgcm9vdCBjYW4gY2hvd24gdGhlIGZpbGUgd2hpY2ggd2lsbCBjbGVhciB0 aGUgZmlsZQo+ID4+ID4+ID5jYXBhYmlsaXR5LCBhZnRlciB3aGljaCBoZSBjYW4gc2V0IGEgbmV3 IG9uZS4gIElmIHRoZSBmaWxlIGlzIG5vdAo+ID4+ID4+ID5vd25lZCBieSBhIHVpZCBtYXBwZWQg aW50byB0aGUgY29udGFpbmVyLCB0aGVuIGNvbnRhaW5lciByb290IGNvdWxkCj4gPj4gPj4gPm5v dCBzZXQgYSBmaWxlY2FwIGFueXdheS4KPiA+PiA+PiAKPiA+PiA+PiBMZXQncyBzYXkgSSBpbnN0 YWxsZWQgYSBjb250YWluZXIgd2hlcmUgYWxsIGZpbGVzIGFyZSBzaWduZWQgYW5kCj4gPj4gPj4g dGh1cyBoYXZlIHNlY3VyaXR5LmltYS4gTm93IGZvciBzb21lIHJlYXNvbiBJIHdhbnQgdG8gcmUt c2lnbiBzb21lCj4gPj4gPj4gb3IgYWxsIGZpbGVzIGluc2lkZSB0aGF0IGNvbnRhaW5lci4gSG93 IHdvdWxkIEkgZG8gdGhhdCA/IFdvdWxkIEkKPiA+PiA+PiBuZWVkIHRvIGdldCByaWQgb2Ygc2Vj dXJpdHkuaW1hIGZpcnN0LCBwb3NzaWJseSBieSBjb3B5aW5nIGVhY2gKPiA+PiA+PiBmaWxlLCBk ZWxldGluZyB0aGUgb3JpZ2luYWwgZmlsZSwgYW5kIHJlbmFtaW5nIHRoZSBjb3BpZWQgZmlsZSB0 bwo+ID4+ID4+IHRoZSBvcmlnaW5hbCBuYW1lLCBvciBzaG91bGQgSSBqdXN0IGJlIGFibGUgdG8g d3JpdGUgb3V0IGEgbmV3Cj4gPj4gPj4gc2lnbmF0dXJlLCB0aHVzIGNyZWF0aW5nIHNlY3VyaXR5 LmltYUB1aWQ9MTAwMCBiZXNpZGVzIHRoZQo+ID4+ID4+IHNlY3VyaXR5LmltYSA/Cj4gPj4gPj4g Cj4gPj4gPj4gICAgU3RlZmFuCj4gPj4gPgo+ID4+ID4gSGkgTWltaSwKPiA+PiA+Cj4gPj4gPiB3 aGF0IGRvIHlvdSB0aGluayBtYWtlcyBtb3N0IHNlbnNlIGZvciBJTUE/Cj4gPj4gCj4gPj4gSSBh bSBnb2luZyB0byBnaXZlIG15IHR3byBjZW50cyBzaW5jZSBJIGhhdmUgYmVlbiB0aGlua2luZyBh Ym91dCB0aGlzLgo+ID4+IAo+ID4+IEZpcnN0IEkgdGhpbmsgdGhpcyBlbnRpcmUgc2NoZW1lIHBs YXlzIGhvYnMgd2l0aCB0aGUgc2VjdXJpdHkuZXZtCj4gPj4gYXR0cmlidXRlIGFzIHNlY3VyaXR5 LmV2bSBuZWVkcyB0byBrbm93IHRoZSBuYW1lcyBvZiB0aGUgeGF0dHJzIHRvCj4gPj4gcHJvdGVj dC4KPiA+PiAKPiA+PiBJIGZvcmdldCB3aGljaCBhdHRyaWJ1dGVzIGhhcyBhIGhhc2ggYW5kIHdo YXQgaGFzIGEgbWVzc2FnZQo+ID4+IGF0aGVudGljYXRpb24gY29kZS4KPiA+Cj4gPiBzZWN1cml0 eS5pbWEgY29udGFpbnMgZWl0aGVyIGEgZmlsZSBoYXNoIG9yIGEgc2lnbmF0dXJlLiAgKGZpbGUg ZGF0YSkKPiA+IHNlY3VyaXR5LmV2bSBjb250YWlucyBlaXRoZXIgYSBzaWduYXR1cmUgb3IgYW4g aG1hYyBvZiB0aGUgc2VjdXJpdHkKPiA+IHhhdHRycyBhbmQgb3RoZXIgZmlsZSBtZXRhZGF0YS4g KGZpbGUgbWV0YS1kYXRhKQo+ID4KPiA+IFRoZSBzYW1lIHJ1bGVzIHdvdWxkIGFwcGx5IHRvIHNl Y3VyaXR5LmV2bSwgYXMgZGVzY3JpYmVkIGluIG15Cj4gPiByZXNwb25zZS4gwqBCYXNlZCBvbiBp dCdzIHZpZXcgb2YgdGhlIHNlY3VyaXR5IHhhdHRycywgZWl0aGVyIHRoZQo+ID4gbmF0aXZlIG9y IG5hbWVzcGFjZSBzZWN1cml0eS5ldm0gd291bGQgYmUgdXBkYXRlZC4KPiA+Cj4gPj4gSWYgdGhl cmUgaXMgYW4gYXR0cmlidXRlIHdpdGggYSBzaW1wbGUgZmlsZSBoYXNoIEkgdGhpbmsgaXQgb25s eSBtYWtlCj4gPj4gc2Vuc2UgZm9yIHRoZSBrZXJuZWwgdG8gdG91Y2ggaXQsIGFuZCBJIGRvbid0 IHNlZSBhbnkgc2Vuc2UgaW4gaGF2aW5nCj4gPj4gbXVsdGlwbGVzLgo+ID4KPiA+IE9ubHkgZmls ZXMgdGhhdCBhcmUgaW4gdGhlIElNQS1hcHByYWlzYWwgcG9saWN5IGlzIHRoZSBmaWxlIGhhc2gK PiA+IGNhbGN1bGF0ZWQgYW5kIHdyaXR0ZW4gb3V0IGFzIHNlY3VyaXR5LmltYS4gwqBEZXBlbmRp bmcgdGhpcyBwb2xpY3ksCj4gPiBkb2VzIHRoZSBzZWN1cml0eS5pbWEgZXhpc3QuIMKgU28gaWYg dGhlIGZpbGUgaXMgaW4gcG9saWN5IGZvciBib3RoIHRoZQo+ID4gbmF0aXZlIGFuZCBuYW1lc3Bh Y2UgcG9saWNpZXMsIGFncmVlZCB0aGUgc2FtZSBoYXNoIGRvZXNuJ3QgbmVlZCB0byBiZQo+ID4g d3JpdHRlbiBhcyB0d28gZGlmZmVyZW50IHhhdHRycy4KPiA+Cj4gPj4gSWYgdGhlcmUgaXMgYW4g YXR0cmlidXRlIHdpdGggYSBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKHJvdWdobHkgYQo+ ID4+IHNpZ25lZCBoYXNoKSBpdCBtYWtlcyBzZW5zZSB0byBoYXZlIHRoYXQgdG8gYmUgdGllZCB0 byB0aGUga2VybmVsIGtleQo+ID4+IHJpbmcgdGhhdCBjb250cm9sbHMgdGhlIGtleXMuICAoV2hp Y2ggcHJvYmFibHkgbWVhbnMgYSBwZXIgdXNlcgo+ID4+IG5hbWVzcGFjZSB0aGluZyBhdCBzb21l IHBvaW50KS4gIEJ1dCBhZ2FpbiBwcmV0dHkgdW50b3VjaGFibGUgb3RoZXJ3aXNlLgo+ID4KPiA+ IFJpZ2h0LCB0aGUgbmFtZXNwYWNlIHdvdWxkIHJlcXVpcmUgaXQncyBvd24gRVZNIGtleS4gCj4g Pgo+ID4+IFdoaWNoIGJyaW5ncyB1cyB0byB0aGUgc2VtYW50aWMgcXVlc3Rpb24gb2Ygd291bGQg aXQgYmUgbmljZSB0byBoYXZlCj4gPj4gc3RhY2tlZCBJTUEvRVZNIG9uIHRoZSBzYW1lIGZpbGUu Cj4gPj4gCj4gPj4gSSByZWFsbHkgZG9uJ3QgdGhpbmsgd2UgZG8uICBJIHRoaW5rIGFsbG93aW5n IG11bHRpcGxlIGtleXMgZm9yCj4gPj4gZGlmZmVyZW50IHBhcnQgb2YgdHJ1c3RpbmcgZmlsZXMg aXMgZWFzeSBlbm91Z2ggdGhhdCB3ZSBzaG91bGQgaGF2ZSBubwo+ID4+IG5lZWQgdG8gZmlnaHQg b3ZlciB3aGljaCBrZXlzIGRvIHdoaWNoLgo+ID4KPiA+IFdlIGRlZmluaXRlbHkgd2FudCB0byBz dXBwb3J0IGRpZmZlcmVudCBwb2xpY2llcyBvbiB0aGUgbmF0aXZlIGFuZCBpbgo+ID4gdGhlIG5h bWVzcGFjZSB3aXRoIGRpZmZlcmVudCBrZXlzIGFuZCBrZXlyaW5ncy4KPiA+Cj4gPiBSZWZlciB0 byBNZWhtZXQgS2FheWxhcCdzIHJlY2VudCBwb3N0LCB3aGljaCByZWZlcnMgdG8gYSBQb0MgdmVy c2lvbgo+ID4gb2YgSU1BIG5hbWVzcGFjaW5nIC0ga2VybnNlYy5vcmcvcGlwZXJtYWlsL2xpbnV4 LXNlY3VyaXR5LW1vZHVsZS0KPiA+IGFyY2hpdmUvMjAxNy1KdWx5LzAwMjI4Ni5odG1sLgo+ID4K PiA+PiBMb29raW5nIGF0IGludGVncml0eS5oIEkgc2VlIHNpZ25hdHVyZV92Ml9oZHIgdGhhdCBo YXMgYSBrZXlpZC4gIEFueSB1c2UKPiA+PiBjYXNlIEkgY2FuIHRoaW5rIG9mIGZvciBkaXN0cmli dXRpbmcgYSBkaXN0cmlidXRpb24gaW1hZ2Ugd2l0aCBpbWEvZXZtCj4gPj4geGF0dHJzIHdpbGwg bmVlZCB0byB1c2UgYXN5bW1ldHJpYyBrZXlzIGFrYSBwdWJsaWMvcHJpdmF0ZSBrZXlwYWlycyBz bwo+ID4+IHRoYXQgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIGNvbnRlbnQgZG9lcyBub3QgZ2l2ZSBh d2F5IHRoZWlyIHByaXZhdGUKPiA+PiBrZXlzLgo+ID4KPiA+IEFncmVlZC4KPiA+Cj4gPj4gR2l2 ZW4gdGhhdCB1c2VmdWxseSB3ZSBhcmUgdGFsa2luZyBhYm91dCBjb250ZW50IHRoYXQgc2hvdWxk IGJlCj4gPj4gY29ubmVjdGVkIHRvIGtleXMgaW4gb25lIHdheSBvciBhbm90aGVyIEkgZG9uJ3Qg YmVsaWV2ZSBpdCBldmVuIG1ha2VzCj4gPj4gc2Vuc2UgYXQgdGhpcyBwb2ludCB0byBhdHRlbXB0 IHRvIHVzZSB1aWRzIGZvciBkZWFsaW5nIHdpdGggaW1hIGFuZAo+ID4+IGV2bSBjb250ZW50Lgo+ ID4KPiA+IFdlIG5lZWQgdG8gcmVzb2x2ZSB0aGUgeGF0dHIgaXNzdWUgaW4gb3JkZXIgdG8gbmFt ZXNwYWNlIElNQS0KPiA+IGFwcHJhaXNhbC7CoAo+IAo+IAo+IE1pbWkgSSBoYXZlIHR3byBxdWVz dGlvbnM6Cj4gCj4gYSkgSXMgdGhlIGtleWlkIGVub3VnaCB0byBkaXN0aW5ndWlzaCB0aGUgc2Vj dXJpdHkuaW1hIGFuZCBzZWN1cml0eS5ldm0KPiAgICB4YXR0cnMgb2Ygb25lIGNvbnRhaW5lciBm cm9tIGFub3RoZXIgY29udGFpbmVyIGFuZCBmcm9tIG5hdGl2ZT8gIE9yCj4gICAgZG8gd2UgaGF2 ZSBzb21lIGltcG9ydGFudCBzZWN1cml0eSB4YXR0cnMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3aXRo Cj4gICAga2V5cyB0aGF0IGRvbid0IGhhdmUgYSBrZXlpZD8KPiAKPiBiKSBDYW4gd2UgcmVhc29u YWJseSBsaXZlIHdpdGggYSBsaW1pdGF0aW9uIHRoYXQgdGhlIG5hdGl2ZSBhbmQgdGhlCj4gICAg bmFtZXNwYWNlJ2QgcG9saWNpZXMgZG9uJ3QgaW50ZXJzZWN0PyAgT3IgaW4gdGhlIGNhc2Ugb2Yg YW4KPiAgICBpbnRlcmVzZWN0aW9uIHRoZSBuYXRpdmUgcG9saWN5IGlzIHRoZSBvbmx5IG9uZSB0 aGF0IGlzIGV4ZWN1dGVkPwo+IAo+IEkgc3VibWl0IHRoYXQgaWYgdGhlIGFuc3dlciBpcyBrZXlp ZHMgYXJlIGFsd2F5cyBwcmVzZW50LCBhbmQgd2UgY2FuCj4gbGl2ZSB3aXRoIHRoZSBuYXRpdmUg cG9saWN5IHRha2luZyBwcmVjZWRlbmNlIG92ZXIgdGhlIGNvbnRhaW5lciBwb2xpY3kKPiB0aGVu IHdlIGhhdmUgYSBzb2x1dGlvbiB0byB0aGUgSU1BIHhhdHRycy4KCklNQS1tZWFzdXJlbWVudCBp cyBoaWVyYWNoaWNhbCwgbWVhbmluZyB0aGF0IHRoZSBtZWFzdXJlbWVudCBwb2xpY3kKZGV0ZXJt aW5lcyB3aGV0aGVyIHRoZSBtZWFzdXJlbWVudCBleGlzdHMgaW4gdGhlIG5hdGl2ZSwgdGhlCmNv bnRhaW5lciwgb3IgYm90aCBtZWFzdXJlbWVudCBsaXN0cy4KCk9uZSBvZiB0aGUgbWFpbiBuYW1l c3BhY2luZyB1c2UgY2FzZXMgZm9yIElNQS1hcHByYWlzYWwgaXMgdGhlIGFiaWxpdHkKdG8gbGlt aXQgcnVubmluZyBhbiBleGVjdXRhYmxlIHRvIGEgcGFydGljdWxhciBjb250YWluZXIuIMKgU28g dW5saWtlCklNQS1tZWFzdXJlbWVudCwgd2hpY2ggaXMgaGllcmFyY2hpY2FsLCB0aGUgSU1BLWFw cHJhaXNhbCBuYW1lc3BhY2UKcG9saWN5IHRha2VzIHByZWNlZGVuY2Ugb3ZlciB0aGUgbmF0aXZl IHBvbGljeS4KCk1pbWkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCkNvbnRhaW5lcnMgbWFpbGluZyBsaXN0CkNvbnRhaW5lcnNAbGlzdHMubGludXgtZm91 bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxtYW4vbGlz dGluZm8vY29udGFpbmVycw== From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.vnet.ibm.com (Mimi Zohar) Date: Sun, 16 Jul 2017 07:25:59 -0400 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: 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> <1500060374.3583.57.camel@linux.vnet.ibm.com> Message-ID: <1500204359.3583.126.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 19:02 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote: > >> "Serge E. Hallyn" writes: > >> > >> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): > >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: > >> >> >Quoting Stefan Berger (stefanb at 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 at ... 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 at 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 at 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. > > > > security.ima contains either a file hash or a signature. (file data) > > security.evm contains either a signature or an hmac of the security > > xattrs and other file metadata. (file meta-data) > > > > The same rules would apply to security.evm, as described in my > > response. ?Based on it's view of the security xattrs, either the > > native or namespace security.evm would be updated. > > > >> 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. > > > > Only files that are in the IMA-appraisal policy is the file hash > > calculated and written out as security.ima. ?Depending this policy, > > does the security.ima exist. ?So if the file is in policy for both the > > native and namespace policies, agreed the same hash doesn't need to be > > written as two different xattrs. > > > >> 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. > > > > Right, the namespace would require it's own EVM key. > > > >> 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. > > > > We definitely want to support different policies on the native and in > > the namespace with different keys and keyrings. > > > > Refer to Mehmet Kaaylap's recent post, which refers to a PoC version > > of IMA namespacing - kernsec.org/pipermail/linux-security-module- > > archive/2017-July/002286.html. > > > >> 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. > > > > Agreed. > > > >> 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. > > > > We need to resolve the xattr issue in order to namespace IMA- > > appraisal.? > > > Mimi I have two questions: > > a) Is the keyid enough to distinguish the security.ima and security.evm > xattrs of one container from another container and from native? Or > do we have some important security xattrs that are associated with > keys that don't have a keyid? > > b) Can we reasonably live with a limitation that the native and the > namespace'd policies don't intersect? Or in the case of an > interesection the native policy is the only one that is executed? > > I submit that if the answer is keyids are always present, and we can > live with the native policy taking precedence over the container policy > then we have a solution to the IMA xattrs. IMA-measurement is hierachical, meaning that the measurement policy determines whether the measurement exists in the native, the container, or both measurement lists. One of the main namespacing use cases for IMA-appraisal is the ability to limit running an executable to a particular container. ?So unlike IMA-measurement, which is hierarchical, the IMA-appraisal namespace policy takes precedence over the native policy. 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="===============8783620993351889092==" MIME-Version: 1.0 From: Mimi Zohar To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Sun, 16 Jul 2017 07:25:59 -0400 Message-ID: <1500204359.3583.126.camel@linux.vnet.ibm.com> In-Reply-To: List-Id: --===============8783620993351889092== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > = > > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote: > >> "Serge E. Hallyn" writes: > >> = > >> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com): > >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: > >> >> >Quoting Stefan Berger (stefanb(a)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(a)... attr= ibute ? > >> >> >>>>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(a)ui= d=3D<> 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 xat= trs > >> >> >Not really. If the file is owned by a uid mapped into the contain= er, > >> >> >then the container root can chown the file which will clear the fi= le > >> >> >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(a)uid=3D1000 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. > > > > security.ima contains either a file hash or a signature. (file data) > > security.evm contains either a signature or an hmac of the security > > xattrs and other file metadata. (file meta-data) > > > > The same rules would apply to security.evm, as described in my > > response. =C2=A0Based on it's view of the security xattrs, either the > > native or namespace security.evm would be updated. > > > >> 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. > > > > Only files that are in the IMA-appraisal policy is the file hash > > calculated and written out as security.ima. =C2=A0Depending this policy, > > does the security.ima exist. =C2=A0So if the file is in policy for both= the > > native and namespace policies, agreed the same hash doesn't need to be > > written as two different xattrs. > > > >> 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 otherwis= e. > > > > Right, the namespace would require it's own EVM key. = > > > >> 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. > > > > We definitely want to support different policies on the native and in > > the namespace with different keys and keyrings. > > > > Refer to Mehmet Kaaylap's recent post, which refers to a PoC version > > of IMA namespacing - kernsec.org/pipermail/linux-security-module- > > archive/2017-July/002286.html. > > > >> Looking at integrity.h I see signature_v2_hdr that has a keyid. Any u= se > >> 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. > > > > Agreed. > > > >> 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. > > > > We need to resolve the xattr issue in order to namespace IMA- > > appraisal.=C2=A0 > = > = > Mimi I have two questions: > = > a) Is the keyid enough to distinguish the security.ima and security.evm > xattrs of one container from another container and from native? Or > do we have some important security xattrs that are associated with > keys that don't have a keyid? > = > b) Can we reasonably live with a limitation that the native and the > namespace'd policies don't intersect? Or in the case of an > interesection the native policy is the only one that is executed? > = > I submit that if the answer is keyids are always present, and we can > live with the native policy taking precedence over the container policy > then we have a solution to the IMA xattrs. IMA-measurement is hierachical, meaning that the measurement policy determines whether the measurement exists in the native, the container, or both measurement lists. One of the main namespacing use cases for IMA-appraisal is the ability to limit running an executable to a particular container. =C2=A0So unlike IMA-measurement, which is hierarchical, the IMA-appraisal namespace policy takes precedence over the native policy. Mimi --===============8783620993351889092==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751265AbdGPL1g (ORCPT ); Sun, 16 Jul 2017 07:27:36 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:51999 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751087AbdGPL1d (ORCPT ); Sun, 16 Jul 2017 07:27:33 -0400 Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces From: Mimi Zohar To: "Eric W. Biederman" Cc: "Serge E. Hallyn" , 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 Date: Sun, 16 Jul 2017 07:25:59 -0400 In-Reply-To: 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> <1500060374.3583.57.camel@linux.vnet.ibm.com> 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: 17071611-0040-0000-0000-0000034939AB X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071611-0041-0000-0000-00000CC4EF34 Message-Id: <1500204359.3583.126.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-16_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707160191 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-07-14 at 19:02 -0500, Eric W. Biederman wrote: > Mimi Zohar writes: > > > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote: > >> "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. > > > > security.ima contains either a file hash or a signature. (file data) > > security.evm contains either a signature or an hmac of the security > > xattrs and other file metadata. (file meta-data) > > > > The same rules would apply to security.evm, as described in my > > response.  Based on it's view of the security xattrs, either the > > native or namespace security.evm would be updated. > > > >> 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. > > > > Only files that are in the IMA-appraisal policy is the file hash > > calculated and written out as security.ima.  Depending this policy, > > does the security.ima exist.  So if the file is in policy for both the > > native and namespace policies, agreed the same hash doesn't need to be > > written as two different xattrs. > > > >> 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. > > > > Right, the namespace would require it's own EVM key. > > > >> 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. > > > > We definitely want to support different policies on the native and in > > the namespace with different keys and keyrings. > > > > Refer to Mehmet Kaaylap's recent post, which refers to a PoC version > > of IMA namespacing - kernsec.org/pipermail/linux-security-module- > > archive/2017-July/002286.html. > > > >> 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. > > > > Agreed. > > > >> 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. > > > > We need to resolve the xattr issue in order to namespace IMA- > > appraisal.  > > > Mimi I have two questions: > > a) Is the keyid enough to distinguish the security.ima and security.evm > xattrs of one container from another container and from native? Or > do we have some important security xattrs that are associated with > keys that don't have a keyid? > > b) Can we reasonably live with a limitation that the native and the > namespace'd policies don't intersect? Or in the case of an > interesection the native policy is the only one that is executed? > > I submit that if the answer is keyids are always present, and we can > live with the native policy taking precedence over the container policy > then we have a solution to the IMA xattrs. IMA-measurement is hierachical, meaning that the measurement policy determines whether the measurement exists in the native, the container, or both measurement lists. One of the main namespacing use cases for IMA-appraisal is the ability to limit running an executable to a particular container.  So unlike IMA-measurement, which is hierarchical, the IMA-appraisal namespace policy takes precedence over the native policy. Mimi