From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Magalhaes, Guilherme (Brazil R&D-CL)" Subject: RE: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Date: Thu, 27 Jul 2017 12:51:32 +0000 Message-ID: References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> <1501008554.3689.30.camel@HansenPartnership.com> <20170725190406.GA1883@mail.hallyn.com> <1501009739.3689.33.camel@HansenPartnership.com> <1501012082.27413.17.camel@linux.vnet.ibm.com> <645db815-7773-e351-5db7-89f38cd88c3d@linux.vnet.ibm.com> <20170725204622.GA4969@mail.hallyn.com> <1501016277.27413.50.camel@linux.vnet.ibm.com> <20170725210801.GA5628@mail.hallyn.com> <1501018134.27413.66.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: <1501018134.27413.66.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> Content-Language: en-US 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: Mimi Zohar , "Serge E. Hallyn" Cc: Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , James Bottomley , linux-security-module , ima-devel , Yuqiong Sun List-Id: containers.vger.kernel.org DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWltaSBab2hhciBbbWFp bHRvOnpvaGFyQGxpbnV4LnZuZXQuaWJtLmNvbV0NCj4gU2VudDogdGVyw6dhLWZlaXJhLCAyNSBk ZSBqdWxobyBkZSAyMDE3IDE4OjI5DQo+IFRvOiBTZXJnZSBFLiBIYWxseW4gPHNlcmdlQGhhbGx5 bi5jb20+DQo+IENjOiBNZWhtZXQgS2F5YWFscCA8bWtheWFhbHBAY3MuYmluZ2hhbXRvbi5lZHU+ OyBZdXFpb25nIFN1bg0KPiA8c3VueXVxaW9uZzE5ODhAZ21haWwuY29tPjsgY29udGFpbmVycyA8 Y29udGFpbmVyc0BsaXN0cy5saW51eC0NCj4gZm91bmRhdGlvbi5vcmc+OyBsaW51eC1rZXJuZWwg PGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+OyBEYXZpZCBTYWZmb3JkDQo+IDxkYXZpZC5z YWZmb3JkQGdlLmNvbT47IEphbWVzIEJvdHRvbWxleQ0KPiA8SmFtZXMuQm90dG9tbGV5QEhhbnNl blBhcnRuZXJzaGlwLmNvbT47IGxpbnV4LXNlY3VyaXR5LW1vZHVsZSA8bGludXgtDQo+IHNlY3Vy aXR5LW1vZHVsZUB2Z2VyLmtlcm5lbC5vcmc+OyBpbWEtZGV2ZWwgPGxpbnV4LWltYS0NCj4gZGV2 ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0PjsgWXVxaW9uZyBTdW4gPHN1bnlAdXMuaWJtLmNvbT4N Cj4gU3ViamVjdDogUmU6IFtMaW51eC1pbWEtZGV2ZWxdIFtSRkMgUEFUQ0ggMS81XSBpbWE6IGV4 dGVuZCBjbG9uZSgpIHdpdGggSU1BDQo+IG5hbWVzcGFjZSBzdXBwb3J0DQo+IA0KPiBPbiBUdWUs IDIwMTctMDctMjUgYXQgMTY6MDggLTA1MDAsIFNlcmdlIEUuIEhhbGx5biB3cm90ZToNCj4gPiBP biBUdWUsIEp1bCAyNSwgMjAxNyBhdCAwNDo1Nzo1N1BNIC0wNDAwLCBNaW1pIFpvaGFyIHdyb3Rl Og0KPiA+ID4gT24gVHVlLCAyMDE3LTA3LTI1IGF0IDE1OjQ2IC0wNTAwLCBTZXJnZSBFLiBIYWxs eW4gd3JvdGU6DQo+ID4gPiA+IE9uIFR1ZSwgSnVsIDI1LCAyMDE3IGF0IDA0OjExOjI5UE0gLTA0 MDAsIFN0ZWZhbiBCZXJnZXIgd3JvdGU6DQo+ID4gPiA+ID4gT24gMDcvMjUvMjAxNyAwMzo0OCBQ TSwgTWltaSBab2hhciB3cm90ZToNCj4gPiA+ID4gPiA+T24gVHVlLCAyMDE3LTA3LTI1IGF0IDEy OjA4IC0wNzAwLCBKYW1lcyBCb3R0b21sZXkgd3JvdGU6DQo+ID4gPiA+ID4gPj5PbiBUdWUsIDIw MTctMDctMjUgYXQgMTQ6MDQgLTA1MDAsIFNlcmdlIEUuIEhhbGx5biB3cm90ZToNCj4gPiA+ID4g PiA+Pj5PbiBUdWUsIEp1bCAyNSwgMjAxNyBhdCAxMTo0OToxNEFNIC0wNzAwLCBKYW1lcyBCb3R0 b21sZXkgd3JvdGU6DQo+ID4gPiA+ID4gPj4+Pk9uIFR1ZSwgMjAxNy0wNy0yNSBhdCAxMjo1MyAt MDUwMCwgU2VyZ2UgRS4gSGFsbHluIHdyb3RlOg0KPiA+ID4gPiA+ID4+Pj4+T24gVGh1LCBKdWwg MjAsIDIwMTcgYXQgMDY6NTA6MjlQTSAtMDQwMCwgTWVobWV0IEtheWFhbHANCj4gd3JvdGU6DQo+ ID4gPiA+ID4gPj4+Pj4+DQo+ID4gPiA+ID4gPj4+Pj4+RnJvbTogWXVxaW9uZyBTdW4gPHN1bnlA dXMuaWJtLmNvbT4NCj4gPiA+ID4gPiA+Pj4+Pj4NCj4gPiA+ID4gPiA+Pj4+Pj5BZGQgbmV3IENP TkZJR19JTUFfTlMgY29uZmlnIG9wdGlvbi4gIExldCBjbG9uZSgpIGNyZWF0ZSBhDQo+ID4gPiA+ ID4gPj4+Pj4+bmV3IElNQSBuYW1lc3BhY2UgdXBvbiBDTE9ORV9ORVdOUyBmbGFnLiBBZGQgaW1h X25zDQo+IGRhdGENCj4gPiA+ID4gPiA+Pj4+Pj5zdHJ1Y3R1cmUgaW4gbnNwcm94eS4gaW1hX25z IGlzIGFsbG9jYXRlZCBhbmQgZnJlZWQgdXBvbg0KPiA+ID4gPiA+ID4+Pj4+PklNQSBuYW1lc3Bh Y2UgY3JlYXRpb24gYW5kIGV4aXQuIEN1cnJlbnRseSwgdGhlIGltYV9ucw0KPiA+ID4gPiA+ID4+ Pj4+PmNvbnRhaW5zIG5vIHVzZWZ1bCBJTUEgZGF0YSBidXQgb25seSBhIGR1bW15IGludGVyZmFj ZS4NCj4gPiA+ID4gPiA+Pj4+Pj5UaGlzIHBhdGNoIGNyZWF0ZXMgdGhlIGZyYW1ld29yayBmb3Ig bmFtZXNwYWNpbmcgdGhlDQo+IGRpZmZlcmVudCBhc3BlY3RzIG9mIElNQSAoZWcuDQo+ID4gPiA+ ID4gPj4+Pj4+SU1BLWF1ZGl0LCBJTUEtbWVhc3VyZW1lbnQsIElNQS1hcHByYWlzYWwpLg0KPiA+ ID4gPiA+ID4+Pj4+Pg0KPiA+ID4gPiA+ID4+Pj4+PlNpZ25lZC1vZmYtYnk6IFl1cWlvbmcgU3Vu IDxzdW55QHVzLmlibS5jb20+DQo+ID4gPiA+ID4gPj4+Pj4+DQo+ID4gPiA+ID4gPj4+Pj4+Q2hh bmdlbG9nOg0KPiA+ID4gPiA+ID4+Pj4+PiogVXNlIENMT05FX05FV05TIGluc3RlYWQgb2YgYSBu ZXcgQ0xPTkVfTkVXSU1BIGZsYWcNCj4gPiA+ID4gPiA+Pj4+PkhpLA0KPiA+ID4gPiA+ID4+Pj4+ DQo+ID4gPiA+ID4gPj4+Pj5TbyB0aGlzIG1lYW5zIHRoYXQgZXZlcnkgbW91bnQgbmFtZXNwYWNl IGNsb25lIHdpbGwgY2xvbmUgYQ0KPiA+ID4gPiA+ID4+Pj4+bmV3IElNQSBuYW1lc3BhY2UuICBJ cyB0aGF0IHJlYWxseSBvaz8NCj4gPiA+ID4gPiA+Pj4+QmFzZWQgb24gd2hhdDogc3BhY2UgY29u Y2VybnMgKHN0cnVjdCBpbWFfbnMgaXMgcmVhc29uYWJseQ0KPiBzbWFsbCk/DQo+ID4gPiA+ID4g Pj4+Pm9yIHdoZXRoZXIgdHlpbmcgaXQgdG8gdGhlIG1vdW50IG5hbWVzcGFjZSBpcyB0aGUgY29y cmVjdA0KPiA+ID4gPiA+ID4+Pj50aGluZyB0byBkby4gIE9uDQo+ID4gPiA+ID4gPj4+TW9zdGx5 IHRoZSBsYXR0ZXIuICBUaGUgb3RoZXIgd291bGQgYmUgbm90IHNvIG11Y2ggc3BhY2UNCj4gPiA+ ID4gPiA+Pj5jb25jZXJucyBhcyB0aW1lIGNvbmNlcm5zLiAgTWFueSB0aGluZ3MgdXNlIG5ldyBt b3VudHMNCj4gPiA+ID4gPiA+Pj5uYW1lc3BhY2VzLCBhbmQgd2Ugd291bGRuJ3Qgd2FudCBtdWx0 aXBsZSBJTUEgY2FsbHMgb24gYWxsDQo+ID4gPiA+ID4gPj4+ZmlsZSBhY2Nlc3NlcyBieSBhbGwg b2YgdGhvc2UuDQo+ID4gPiA+ID4gPj4+DQo+ID4gPiA+ID4gPj4+PnRoZSBsYXR0ZXIsIGl0IGRv ZXMgc2VlbSB0aGF0IHRoaXMgc2hvdWxkIGJlIGEgcHJvcGVydHkgb2YNCj4gPiA+ID4gPiA+Pj4+ ZWl0aGVyIHRoZSBtb3VudCBvciB1c2VyIG5zIHJhdGhlciB0aGFuIGl0cyBvd24gc2VwYXJhdGUg bnMuDQo+ID4gPiA+ID4gPj4+PkkgY291bGQgc2VlIGEgdXNlIHdoZXJlIGV2ZW4gYSBjb250YWlu ZXIgbWlnaHQgd2FudCBtdWx0aXBsZQ0KPiA+ID4gPiA+ID4+Pj5pbWEga2V5cmluZ3Mgd2l0aGlu IHRoZSBjb250YWluZXIgKHNheSBjb250YWluZXJpc2VkIGFwYWNoZQ0KPiA+ID4gPiA+ID4+Pj5z ZXJ2aWNlIHdpdGggbXVsdGlwbGUgdGVuYW50cyksIHNvIGluc3RpbmN0IHRlbGxzIG1lIHRoYXQN Cj4gPiA+ID4gPiA+Pj4+bW91bnQgbnMgaXMgdGhlIGNvcnJlY3QgZ3JhbnVsYXJpdHkgZm9yIHRo aXMuDQo+ID4gPiA+ID4gPj4+SSB3b25kZXIgd2hldGhlciB3ZSBjb3VsZCB1c2UgZWNobyAxID4N Cj4gPiA+ID4gPiA+Pj4vc3lzL2tlcm5lbC9zZWN1cml0eS9pbWEvbmV3bnMgYXMgdGhlIHRyaWdn ZXIgZm9yIHJlcXVlc3RpbmcNCj4gPiA+ID4gPiA+Pj5hIG5ldyBpbWEgbnMgb24gdGhlIG5leHQg Y2xvbmUoQ0xPTkVfTkVXTlMpLg0KPiA+ID4gPiA+ID4+SSBjb3VsZCBnbyB3aXRoIHRoYXQsIGJ1 dCB3aGF0IGFib3V0IHRoZSB0cmlnZ2VyIGJlaW5nDQo+ID4gPiA+ID4gPj5pbnN0YWxsaW5nIG9y IHVwZGF0aW5nIHRoZSBrZXlyaW5nPyAgVGhhdCdzIHRoZSBvbmx5IG9wZXJhdGlvbg0KPiA+ID4g PiA+ID4+dGhhdCBuZWVkcyBuYW1lc3BhY2Ugc2VwYXJhdGlvbiwgc28gb24gbW91bnQgbnMgY2xv bmUsIHlvdSBnZXQNCj4gPiA+ID4gPiA+PmEgcG9pbnRlciB0byB0aGUgb2xkIGltYV9ucyB1bnRp bCB5b3UgZG8gc29tZXRoaW5nIHRoYXQNCj4gPiA+ID4gPiA+PnJlcXVpcmVzIGEgbmV3IGtleSwg d2hpY2ggdGhlbiB0cmlnZ2VycyB0aGUgY29weSBvZiB0aGUgbmFtZXNwYWNlDQo+IGFuZCBpbnN0 YWxsaW5nIGl0Pw0KPiA+ID4gPiA+ID5JdCBpc24ndCBqdXN0IHRoZSBrZXlyaW5ncyB0aGF0IG5l ZWQgdG8gYmUgbmFtZXNwYWNlZCwgYnV0IHRoZQ0KPiA+ID4gPiA+ID5tZWFzdXJlbWVudCBsaXN0 IGFuZCBwb2xpY3kgYXMgd2VsbC4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPklNQS1tZWFzdXJl bWVudCwgSU1BLWFwcHJhaXNhbCBhbmQgSU1BLWF1ZGl0IGFyZSBhbGwgcG9saWN5DQo+IGJhc2Vk Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+QXMgc29vbiBhcyB0aGUgbmFtZXNwYWNlIHN0YXJ0 cywgbWVhc3VyZW1lbnRzIHNob3VsZCBiZSBhZGRlZA0KPiA+ID4gPiA+ID50byB0aGUgbmFtZXNw YWNlIHNwZWNpZmljIG1lYXN1cmVtZW50IGxpc3QsIG5vdCBpdCdzIHBhcmVudC4NCj4gPiA+ID4N Cj4gPiA+ID4gU2hvdWxkbid0IGl0IGJlIGJvdGg/DQo+ID4gPg0KPiA+ID4gVGhlIHBvbGljeSBk ZWZpbmVzIHdoaWNoIGZpbGVzIGFyZSBtZWFzdXJlZC4gwqBUaGUgbmFtZXNwYWNlIHBvbGljeQ0K PiA+ID4gY291bGQgYmUgZGlmZmVyZW50IHRoYW4gaXQncyBwYXJlbnQncyBwb2xpY3ksIGFuZCB0 aGUgcGFyZW50J3MNCj4gPiA+IHBvbGljeSBjb3VsZCBiZSBkaWZmZXJlbnQgdGhhbiB0aGUgbmF0 aXZlIHBvbGljeS4gwqBCYXNpY2FsbHksIGZpbGUNCj4gPiA+IG1lYXN1cmVtZW50cyBuZWVkIHRv IGJlIGFkZGVkIHRvIHRoZSBuYW1lc3BhY2UgbWVhc3VyZW1lbnQgbGlzdCwNCj4gPiA+IHJlY3Vy c2l2ZWx5LCB1cCB0byB0aGUgbmF0aXZlIG1lYXN1cmVtZW50IGxpc3QuDQo+ID4NCj4gPiBZZXMs IGJ1dCBpZiBhIHRhc2sgdDEgaXMgaW4gbmFtZXNwYWNlIG5zMiB3aGljaCBpcyBhIGNoaWxkIG9m DQo+ID4gbmFtZXNwYWNlIG5zMSwgYW5kIGl0IGFjY2Vzc2VzIGEgZmlsZSB3aGljaCBuczEncyBw b2xpY3kgc2F5cyBtdXN0IGJlDQo+ID4gbWVhc3VyZWQsIHRoZW4gd2lsbCBuczEncyByZXF1aXJl ZCBtZWFzdXJlbWVudCBoYXBwZW4gKGFuZCBiZQ0KPiBhcHBlbmRlZA0KPiA+IHRvIHRoZSBuczEg bWVhc3VyZW1lbnQgbGlzdCksIHdoZXRoZXIgb3Igbm90IG5zMidzIHBvbGljeSByZXF1aXJlcyBp dD8NCj4gDQo+IFllcywgYXMgdGhlIGZpbGUgbmVlZHMgdG8gYmUgbWVhc3VyZWQgb25seSBpbiB0 aGUgbnMxIHBvbGljeSwgdGhlDQo+IG1lYXN1cmVtZW50IHdvdWxkIGV4aXN0IGluIHRoZSBuczEg bWVhc3VyZW1lbnQgbGlzdCwgYnV0IG5vdCBpbiB0aGUNCj4gbnMyIG1lYXN1cmVtZW50IGxpc3Qu IMKgVGhlIHBzZXVkbyBjb2RlIHNuaXBwZXQgYmVsb3cgbWlnaHQgaGVscC4NCg0KVGhpcyBhbGdv cml0aG0gaXMgcG90ZW50aWFsbHkgZXh0ZW5kaW5nIGEgUENSIGluIFRQTSBtdWx0aXBsZSB0aW1l cyBmb3IgYSBzaW5nbGUgZmlsZSBldmVudCB1bmRlciBhIGdpdmVuIG5hbWVzcGFjZSBhbmQgZHVw bGljYXRpbmcgZW50cmllcy4gQW55IGNvbmNlcm5zIHdpdGggcGVyZm9ybWFuY2UgYW5kIG1lbW9y eSBmb290cHJpbnQ/DQpXaGF0IGlzIHRoZSByZWFzb24gdG8gYWRkaW5nIGEgbWVhc3VyZW1lbnQg dG8gbXVsdGlwbGUgbmFtZXNwYWNlIG1lYXN1cmVtZW50IGxpc3RzPyBIb3cgYXJlIHRoZXNlIGxp c3RzIGdvaW5nIHRvIGJlIHVzZWQ/IEZvciBSZW1vdGUgQXR0ZXN0YXRpb24gd2UgbmVlZCBhIHNp bmdsZSBsaXN0ICh0aGUgbmF0aXZlIG9uZSkgd2hpY2ggaGFzIHRoZSBjb21wbGV0ZSBsaXN0IG9m IG1lYXN1cmVtZW50cyBhbmQgaW4gdGhlIHNhbWUgb3JkZXIgdGhleSB3ZXJlIGV4dGVuZGVkIGlu IHRoZSBUUE0uIEFkZGl0aW9uYWxseSwgd2hlbiBuYW1lc3BhY2VzIGFyZSByZWxlYXNlZCwgd291 bGQgdGhlIG1lYXN1cmVtZW50IGxpc3QgdW5kZXIgdGhhdCBuYW1lc3BhY2UgZGlzYXBwZWFyPyBI b3cgdG8gc3RvcmUgdGhpcyBsaXN0IGNvbnNpZGVyaW5nIHRoZSBuYW1lc3BhY2VzIG1heSBoYXZl IGEgc2hvcnQgbGlmZSBhbmQgYmUgcmV1c2VkIHRob3VzYW5kcyBvZiB0aW1lcz8NClNob3VsZCB0 aGUgbmF0aXZlIG1lYXN1cmVtZW50IGxpc3QgaGF2ZSBhbGwgbWVhc3VyZW1lbnRzIHRyaWdnZXJl ZCBpbiB0aGUgd2hvbGUgc3lzdGVtLCBpbmNsdWRpbmcgdGhlIG9uZXMgbWFkZSB1bmRlciBvdGhl ciBuYW1lc3BhY2VzPyBGb2xsb3dpbmcgdGhlIGFsZ29yaXRobSBiZWxvdywgaWYgdGhlIGZpbGUg aXMgbm90IGluIHRoZSBwb2xpY3kgb2YgdGhlICduYXRpdmUnL2luaXRpYWwgbmFtZXNwYWNlLCB0 aGUgbWVhc3VyZW1lbnQgaXMgbm90IGFkZGVkIHRvIHRoZSBuYXRpdmUgbWVhc3VyZW1lbnQgbGlz dC4NCkVhY2ggbWVhc3VyZW1lbnQgZW50cnkgaW4gdGhlIGxpc3QgY291bGQgaGF2ZSBuZXcgZmll bGRzIHRvIGlkZW50aWZ5IHRoZSBuYW1lc3BhY2UuIFNpbmNlIHRoZSBuYW1lc3BhY2VzIGNhbiBi ZSByZXVzZWQsIGEgdGltZXN0YW1wIG9yIG90aGVycyBmaWVsZHMgY291bGQgYmUgYWRkZWQgdG8g dW5pcXVlbHkgaWRlbnRpZnkgdGhlIG5hbWVzcGFjZSBpZC4NClJlZ2FyZGluZyBuYW1lc3BhY2Ug aGllcmFyY2h5IGFuZCBJTUEgcG9saWN5LCB3ZSBjb3VsZCBhc3N1bWUgdGhhdCBpZiBhIGdpdmVu IG5hbWVzcGFjZSBoYXMgbm8gcG9saWN5IHNldCwgdGhlIHBvbGljeSBvZiB0aGF0IG5hbWVzcGFj ZSBwYXJlbnQgaXMgYXBwbGllZCBhbmQgdGhlbiB0aGUgbmF0aXZlL2luaXRpYWwgbmFtZXNwYWNl IHNob3VsZCBhbHdheXMgaGF2ZSBhIHNldCBwb2xpY3kuDQoNCj4gDQo+IGRvIHsNCj4gICAgLg0K PiAgICAuDQo+IA0KPiAgICAvKiBjYWxjdWxhdGUgZmlsZSBoYXNoIGJhc2VkIG9uIHhhdHRyIGFs Z29yaXRobSAqLw0KPiAgICBjb2xsZWN0X21lYXN1cmVtZW50KCkNCj4gDQo+ICAgIC8qIHJlY3Vy c2l2ZWx5IGFkZGVkIHRvIGVhY2ggbmFtZXNwYWNlIGJhc2VkIG9uIHBvbGljeSAqLw0KPiAgICBp bWFfc3RvcmVfbWVhc3VyZW1lbnQoKQ0KPiANCj4gICAgLyogQmFzZWQgb24gdGhlIHNwZWNpZmlj IG5hbWVzcGFjZSBwb2xpY3kgYW5kIGtleXMuICovDQo+ICAgIGlmICghb25jZSkgew0KPiAgICAg ICAgb25jZSA9IDE7DQo+ICAgICAgICByZXN1bHQgPSBpbWFfYXBwcmFpc2VfbWVhc3VyZW1lbnQo KQ0KPiAgICB9DQo+IA0KPiAgICBpbWFfYXVkaXRfbWVhc3VyZW1lbnQoKQ0KPiANCj4gfSB3aGls ZSAoKG5zID0gbnMtPnBhcmVudCkpOw0KPiANCj4gcmV0dXJuIHJlc3VsdDsNCj4gDQo+IE1pbWkN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ2hlY2sgb3V0IHRoZSB2aWJyYW50 IHRlY2ggY29tbXVuaXR5IG9uIG9uZSBvZiB0aGUgd29ybGQncyBtb3N0IGVuZ2FnaW5nDQo+IHRl Y2ggc2l0ZXMsIFNsYXNoZG90Lm9yZyEgaHR0cDovL3NkbS5saW5rL3NsYXNoZG90DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IExpbnV4LWltYS1k ZXZlbCBtYWlsaW5nIGxpc3QNCj4gTGludXgtaW1hLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5l dA0KPiBodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9saW51eC1p bWEtZGV2ZWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkNvbnRhaW5lcnMgbWFpbGluZyBsaXN0CkNvbnRhaW5lcnNAbGlzdHMubGludXgtZm91bmRhdGlv bi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxtYW4vbGlzdGluZm8v Y29udGFpbmVycw== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751607AbdG0Mvl (ORCPT ); Thu, 27 Jul 2017 08:51:41 -0400 Received: from g2t1383g.austin.hpe.com ([15.233.16.89]:60468 "EHLO g2t1383g.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751125AbdG0Mvh (ORCPT ); Thu, 27 Jul 2017 08:51:37 -0400 From: "Magalhaes, Guilherme (Brazil R&D-CL)" To: Mimi Zohar , "Serge E. Hallyn" CC: Mehmet Kayaalp , Yuqiong Sun , containers , linux-kernel , David Safford , "James Bottomley" , linux-security-module , ima-devel , Yuqiong Sun Subject: RE: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Thread-Topic: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support Thread-Index: AQHTAasZRnYdXqbK8Eu44qjVHwfC/qJk2nOAgAAPogCAAAQnAIAAAV6AgAAK6QCAAAaNgIAACb8AgAADPYCAAALQgIAABdUAgAKLihA= Date: Thu, 27 Jul 2017 12:51:32 +0000 Message-ID: References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> <1501008554.3689.30.camel@HansenPartnership.com> <20170725190406.GA1883@mail.hallyn.com> <1501009739.3689.33.camel@HansenPartnership.com> <1501012082.27413.17.camel@linux.vnet.ibm.com> <645db815-7773-e351-5db7-89f38cd88c3d@linux.vnet.ibm.com> <20170725204622.GA4969@mail.hallyn.com> <1501016277.27413.50.camel@linux.vnet.ibm.com> <20170725210801.GA5628@mail.hallyn.com> <1501018134.27413.66.camel@linux.vnet.ibm.com> In-Reply-To: <1501018134.27413.66.camel@linux.vnet.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=guilherme.magalhaes@hpe.com; x-originating-ip: [15.211.195.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;TU4PR84MB0304;7:YrwalSTvVvSYTgI5ekE8CYbC1ZcSDaqVNoWuuniulEg9lzXPPiM8rhCGdvjC0yrP8tus6GfhfY2yiRR+RIG3j2VCFyBmMUY61eVShIc2rVaBlBj4mhpNS4SDb1yE+NGUUs6iHkHhhE63M//jKjzehdFkm/Mz0WyPQffdQLSglM+T5XY2uGAviTho46JVz2HbDW9WilVPCtkvlo/GZJFfcsydVKGuDc22qUM0FCFE6PKVhmGometwWEhBBgkaS5lzKDMIwaJwRZ9A4+1SWtz3IPzP7xYk5+2QJ7GiINmOIwzww1RW8xMDf1iI3GwOQgLsF9okQ3gK8yBxZZrbpmBPn9S8EjI2elMRgu0880R2qkyIwSKtLJ1Eqiyn6R6HWfDUleslXeLm9y6GB7QqsQCSj1ThQZFTLL8bKYC/0p2iamn6o0baAfFI1OsSy88LPCd4c1W+aPwOiRCyRhDlxZN699YPL0AhNlJisIhBGEbp2Pf6Ij+G7CZxhnxjEFyGAKfICaP9XTsVZ8MeXzTDzWOnhGcMuqbh4d6vPP0Lb2R5pgweyDLaCMNgaANm2Cvn8fVhYrzgIWLb5wKOTgzMYtPtzbhZlWI4r9jvjh9M/xzndAkkwii6PANybt4fQo/YOfxygdfyoJi/vnx0n9aZRIGGrrDKFEeJQZBegfCQi6pV+zudohfzU8woLQH7M5hcNbvvtdfhYfxXTpwu3Vd7bvu/ab4yT6aljDkt2dezrhR5xLBw38KWRsxAw9fNMyUepDnPoBFLrZRux89G1iRSrZDF6sUHe1P2I3y05/N7HN4uIIs= x-ms-office365-filtering-correlation-id: ef9e161d-dc9c-48fe-a004-08d4d4ee3541 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:TU4PR84MB0304; x-ms-traffictypediagnostic: TU4PR84MB0304: x-exchange-antispam-report-test: UriScan:(143289334528602)(192374486261705)(9452136761055)(106981052589767)(42262312472803)(274839183919467)(104084551191319); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:TU4PR84MB0304;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:TU4PR84MB0304; x-forefront-prvs: 03818C953D x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39840400002)(39410400002)(39860400002)(377424004)(24454002)(199003)(377454003)(54534003)(13464003)(189002)(4326008)(6116002)(53936002)(102836003)(39060400002)(50986999)(77096006)(9686003)(55016002)(101416001)(6306002)(54356999)(8676002)(7736002)(53546010)(305945005)(6506006)(966005)(105586002)(38730400002)(7416002)(2900100001)(106356001)(53376002)(3660700001)(3280700002)(76176999)(7696004)(6436002)(54906002)(74316002)(81166006)(5660300001)(8936002)(86362001)(97736004)(2950100002)(93886004)(230783001)(478600001)(3846002)(81156014)(229853002)(14454004)(1720100001)(6246003)(66066001)(2906002)(189998001)(68736007)(25786009)(33656002)(8656003)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:TU4PR84MB0304;H:TU4PR84MB0302.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2017 12:51:32.5943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: TU4PR84MB0304 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v6RCrBr4018970 > -----Original Message----- > From: Mimi Zohar [mailto:zohar@linux.vnet.ibm.com] > Sent: terça-feira, 25 de julho de 2017 18:29 > To: Serge E. Hallyn > Cc: Mehmet Kayaalp ; Yuqiong Sun > ; containers foundation.org>; linux-kernel ; David Safford > ; James Bottomley > ; linux-security-module security-module@vger.kernel.org>; ima-devel devel@lists.sourceforge.net>; Yuqiong Sun > Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA > namespace support > > On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: > > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > > > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp > wrote: > > > > > >>>>>> > > > > > >>>>>>From: Yuqiong Sun > > > > > >>>>>> > > > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a > > > > > >>>>>>new IMA namespace upon CLONE_NEWNS flag. Add ima_ns > data > > > > > >>>>>>structure in nsproxy. ima_ns is allocated and freed upon > > > > > >>>>>>IMA namespace creation and exit. Currently, the ima_ns > > > > > >>>>>>contains no useful IMA data but only a dummy interface. > > > > > >>>>>>This patch creates the framework for namespacing the > different aspects of IMA (eg. > > > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > > > > >>>>>> > > > > > >>>>>>Signed-off-by: Yuqiong Sun > > > > > >>>>>> > > > > > >>>>>>Changelog: > > > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > > > > >>>>>Hi, > > > > > >>>>> > > > > > >>>>>So this means that every mount namespace clone will clone a > > > > > >>>>>new IMA namespace. Is that really ok? > > > > > >>>>Based on what: space concerns (struct ima_ns is reasonably > small)? > > > > > >>>>or whether tying it to the mount namespace is the correct > > > > > >>>>thing to do. On > > > > > >>>Mostly the latter. The other would be not so much space > > > > > >>>concerns as time concerns. Many things use new mounts > > > > > >>>namespaces, and we wouldn't want multiple IMA calls on all > > > > > >>>file accesses by all of those. > > > > > >>> > > > > > >>>>the latter, it does seem that this should be a property of > > > > > >>>>either the mount or user ns rather than its own separate ns. > > > > > >>>>I could see a use where even a container might want multiple > > > > > >>>>ima keyrings within the container (say containerised apache > > > > > >>>>service with multiple tenants), so instinct tells me that > > > > > >>>>mount ns is the correct granularity for this. > > > > > >>>I wonder whether we could use echo 1 > > > > > > >>>/sys/kernel/security/ima/newns as the trigger for requesting > > > > > >>>a new ima ns on the next clone(CLONE_NEWNS). > > > > > >>I could go with that, but what about the trigger being > > > > > >>installing or updating the keyring? That's the only operation > > > > > >>that needs namespace separation, so on mount ns clone, you get > > > > > >>a pointer to the old ima_ns until you do something that > > > > > >>requires a new key, which then triggers the copy of the namespace > and installing it? > > > > > >It isn't just the keyrings that need to be namespaced, but the > > > > > >measurement list and policy as well. > > > > > > > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy > based. > > > > > > > > > > > >As soon as the namespace starts, measurements should be added > > > > > >to the namespace specific measurement list, not it's parent. > > > > > > > > Shouldn't it be both? > > > > > > The policy defines which files are measured.  The namespace policy > > > could be different than it's parent's policy, and the parent's > > > policy could be different than the native policy.  Basically, file > > > measurements need to be added to the namespace measurement list, > > > recursively, up to the native measurement list. > > > > Yes, but if a task t1 is in namespace ns2 which is a child of > > namespace ns1, and it accesses a file which ns1's policy says must be > > measured, then will ns1's required measurement happen (and be > appended > > to the ns1 measurement list), whether or not ns2's policy requires it? > > Yes, as the file needs to be measured only in the ns1 policy, the > measurement would exist in the ns1 measurement list, but not in the > ns2 measurement list.  The pseudo code snippet below might help. This algorithm is potentially extending a PCR in TPM multiple times for a single file event under a given namespace and duplicating entries. Any concerns with performance and memory footprint? What is the reason to adding a measurement to multiple namespace measurement lists? How are these lists going to be used? For Remote Attestation we need a single list (the native one) which has the complete list of measurements and in the same order they were extended in the TPM. Additionally, when namespaces are released, would the measurement list under that namespace disappear? How to store this list considering the namespaces may have a short life and be reused thousands of times? Should the native measurement list have all measurements triggered in the whole system, including the ones made under other namespaces? Following the algorithm below, if the file is not in the policy of the 'native'/initial namespace, the measurement is not added to the native measurement list. Each measurement entry in the list could have new fields to identify the namespace. Since the namespaces can be reused, a timestamp or others fields could be added to uniquely identify the namespace id. Regarding namespace hierarchy and IMA policy, we could assume that if a given namespace has no policy set, the policy of that namespace parent is applied and then the native/initial namespace should always have a set policy. > > do { > . > . > > /* calculate file hash based on xattr algorithm */ > collect_measurement() > > /* recursively added to each namespace based on policy */ > ima_store_measurement() > > /* Based on the specific namespace policy and keys. */ > if (!once) { > once = 1; > result = ima_appraise_measurement() > } > > ima_audit_measurement() > > } while ((ns = ns->parent)); > > return result; > > Mimi > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-ima-devel mailing list > Linux-ima-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-ima-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: guilherme.magalhaes@hpe.com (Magalhaes, Guilherme (Brazil R&D-CL)) Date: Thu, 27 Jul 2017 12:51:32 +0000 Subject: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support In-Reply-To: <1501018134.27413.66.camel@linux.vnet.ibm.com> References: <20170720225033.21298-1-mkayaalp@linux.vnet.ibm.com> <20170720225033.21298-2-mkayaalp@linux.vnet.ibm.com> <20170725175317.GA727@mail.hallyn.com> <1501008554.3689.30.camel@HansenPartnership.com> <20170725190406.GA1883@mail.hallyn.com> <1501009739.3689.33.camel@HansenPartnership.com> <1501012082.27413.17.camel@linux.vnet.ibm.com> <645db815-7773-e351-5db7-89f38cd88c3d@linux.vnet.ibm.com> <20170725204622.GA4969@mail.hallyn.com> <1501016277.27413.50.camel@linux.vnet.ibm.com> <20170725210801.GA5628@mail.hallyn.com> <1501018134.27413.66.camel@linux.vnet.ibm.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org > -----Original Message----- > From: Mimi Zohar [mailto:zohar at linux.vnet.ibm.com] > Sent: ter??a-feira, 25 de julho de 2017 18:29 > To: Serge E. Hallyn > Cc: Mehmet Kayaalp ; Yuqiong Sun > ; containers foundation.org>; linux-kernel ; David Safford > ; James Bottomley > ; linux-security-module security-module at vger.kernel.org>; ima-devel devel at lists.sourceforge.net>; Yuqiong Sun > Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA > namespace support > > On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote: > > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote: > > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote: > > > > On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote: > > > > > On 07/25/2017 03:48 PM, Mimi Zohar wrote: > > > > > >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote: > > > > > >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote: > > > > > >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote: > > > > > >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote: > > > > > >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp > wrote: > > > > > >>>>>> > > > > > >>>>>>From: Yuqiong Sun > > > > > >>>>>> > > > > > >>>>>>Add new CONFIG_IMA_NS config option. Let clone() create a > > > > > >>>>>>new IMA namespace upon CLONE_NEWNS flag. Add ima_ns > data > > > > > >>>>>>structure in nsproxy. ima_ns is allocated and freed upon > > > > > >>>>>>IMA namespace creation and exit. Currently, the ima_ns > > > > > >>>>>>contains no useful IMA data but only a dummy interface. > > > > > >>>>>>This patch creates the framework for namespacing the > different aspects of IMA (eg. > > > > > >>>>>>IMA-audit, IMA-measurement, IMA-appraisal). > > > > > >>>>>> > > > > > >>>>>>Signed-off-by: Yuqiong Sun > > > > > >>>>>> > > > > > >>>>>>Changelog: > > > > > >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag > > > > > >>>>>Hi, > > > > > >>>>> > > > > > >>>>>So this means that every mount namespace clone will clone a > > > > > >>>>>new IMA namespace. Is that really ok? > > > > > >>>>Based on what: space concerns (struct ima_ns is reasonably > small)? > > > > > >>>>or whether tying it to the mount namespace is the correct > > > > > >>>>thing to do. On > > > > > >>>Mostly the latter. The other would be not so much space > > > > > >>>concerns as time concerns. Many things use new mounts > > > > > >>>namespaces, and we wouldn't want multiple IMA calls on all > > > > > >>>file accesses by all of those. > > > > > >>> > > > > > >>>>the latter, it does seem that this should be a property of > > > > > >>>>either the mount or user ns rather than its own separate ns. > > > > > >>>>I could see a use where even a container might want multiple > > > > > >>>>ima keyrings within the container (say containerised apache > > > > > >>>>service with multiple tenants), so instinct tells me that > > > > > >>>>mount ns is the correct granularity for this. > > > > > >>>I wonder whether we could use echo 1 > > > > > > >>>/sys/kernel/security/ima/newns as the trigger for requesting > > > > > >>>a new ima ns on the next clone(CLONE_NEWNS). > > > > > >>I could go with that, but what about the trigger being > > > > > >>installing or updating the keyring? That's the only operation > > > > > >>that needs namespace separation, so on mount ns clone, you get > > > > > >>a pointer to the old ima_ns until you do something that > > > > > >>requires a new key, which then triggers the copy of the namespace > and installing it? > > > > > >It isn't just the keyrings that need to be namespaced, but the > > > > > >measurement list and policy as well. > > > > > > > > > > > >IMA-measurement, IMA-appraisal and IMA-audit are all policy > based. > > > > > > > > > > > >As soon as the namespace starts, measurements should be added > > > > > >to the namespace specific measurement list, not it's parent. > > > > > > > > Shouldn't it be both? > > > > > > The policy defines which files are measured. ??The namespace policy > > > could be different than it's parent's policy, and the parent's > > > policy could be different than the native policy. ??Basically, file > > > measurements need to be added to the namespace measurement list, > > > recursively, up to the native measurement list. > > > > Yes, but if a task t1 is in namespace ns2 which is a child of > > namespace ns1, and it accesses a file which ns1's policy says must be > > measured, then will ns1's required measurement happen (and be > appended > > to the ns1 measurement list), whether or not ns2's policy requires it? > > Yes, as the file needs to be measured only in the ns1 policy, the > measurement would exist in the ns1 measurement list, but not in the > ns2 measurement list. ??The pseudo code snippet below might help. This algorithm is potentially extending a PCR in TPM multiple times for a single file event under a given namespace and duplicating entries. Any concerns with performance and memory footprint? What is the reason to adding a measurement to multiple namespace measurement lists? How are these lists going to be used? For Remote Attestation we need a single list (the native one) which has the complete list of measurements and in the same order they were extended in the TPM. Additionally, when namespaces are released, would the measurement list under that namespace disappear? How to store this list considering the namespaces may have a short life and be reused thousands of times? Should the native measurement list have all measurements triggered in the whole system, including the ones made under other namespaces? Following the algorithm below, if the file is not in the policy of the 'native'/initial namespace, the measurement is not added to the native measurement list. Each measurement entry in the list could have new fields to identify the namespace. Since the namespaces can be reused, a timestamp or others fields could be added to uniquely identify the namespace id. Regarding namespace hierarchy and IMA policy, we could assume that if a given namespace has no policy set, the policy of that namespace parent is applied and then the native/initial namespace should always have a set policy. > > do { > . > . > > /* calculate file hash based on xattr algorithm */ > collect_measurement() > > /* recursively added to each namespace based on policy */ > ima_store_measurement() > > /* Based on the specific namespace policy and keys. */ > if (!once) { > once = 1; > result = ima_appraise_measurement() > } > > ima_audit_measurement() > > } while ((ns = ns->parent)); > > return result; > > Mimi > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-ima-devel mailing list > Linux-ima-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-ima-devel ????{.n?+???????+%?????????w??{.n?+????{??????????v?^?)????w*jg??????????j????G?????? ???j:+v???w?j?m????????w?????f???h?????????