From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Date: Fri, 26 Jan 2018 00:36:48 +0000 Subject: Re: [PATCH v3] fscrypt: add support for the encrypted key type Message-Id: <20180126003648.jtmiznczkinla353@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: base64 List-Id: References: <20180118131359.8365-1-git@andred.net> In-Reply-To: <20180118131359.8365-1-git@andred.net> To: =?iso-8859-1?Q?Andr=E9?= Draszik Cc: linux-kernel@vger.kernel.org, Mimi Zohar , David Howells , James Morris , "Serge E. Hallyn" , "Theodore Y. Ts'o" , Jaegeuk Kim , Kees Cook , Eric Biggers , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org T24gVGh1LCBKYW4gMTgsIDIwMTggYXQgMDE6MTM6NTlQTSArMDAwMCwgQW5kcukgRHJhc3ppayB3 cm90ZToKPiBmc2NyeXB0IHVzZXMgYSBtYXN0ZXIga2V5IGZvciBlYWNoIGRpcmVjdG9yeSBwb2xp Y3kgZnJvbQo+IHdoaWNoIGFsbCBmdXJ0aGVyIGtleXMgZm9yIHRoYXQgcG9saWN5IGFyZSBkZXJp dmVkLCBhbmQKPiBhdCB0aGUgbW9tZW50IHN1Y2ggYSBtYXN0ZXIga2V5IGhhcyB0byBiZSBpbnNl cnRlZCBpbnRvCj4gYSBrZXJuZWwga2V5cmluZyBhcyBhICdsb2dvbicga2V5IGJ5IHVzZXItc3Bh Y2UuCj4gCj4gV2hpbGUgJ2xvZ29uJyBrZXlzIGhhdmUgdGhlIG5pY2UgcHJvcGVydHkgb2Ygbm90 IGJlaW5nCj4gcmVhZGFibGUgYnkgdXNlci1zcGFjZSAoa2V5Y3RsIGR1bXAgZXRjLiksIHRoZSBm c2NyeXB0CgpUaGVyZSBpcyBubyAna2V5Y3RsIGR1bXAnIGNvbW1hbmQuICBQcm9iYWJseSB5b3Ug bWVhbnQgJ2tleWN0bCByZWFkJy4KCj4gbWFzdGVyIGtleSBzdGlsbCBuZWVkcyB0byBiZSBnZW5l cmF0ZWQgaW5pdGlhbGx5LCBpbiBhCj4gc2VjdXJlIHdheSwgYW5kIGl0IG5lZWRzIHRvIGJlIHNh dmVkIHNvbWV3aGVyZSBmb3IKPiBzdWJzZXF1ZW50IHJlYm9vdHMsIGFuZCBoZW5jZSBhbHNvIG5l ZWRzIHNlY3VyaW5nIGl0c2VsZi4KPiAKPiBVc2FnZSBvZiB0aGUgJ2xvZ29uJyBrZXkgbWVhbnMg dGhhdCBpdCBpcyB1cCB0byB1c2VyLXNwYWNlCj4gdG8gZG8gYWxsIHRoYXQsIG9wZW5pbmcgdXAg dGhlIHBvc3NpYmlsaXR5IG9mIGNyZWF0aW5nCj4gY3J5cHRvZ3JhcGhpY2FsbHkgbm9uLXNvdW5k IG1hc3RlciBrZXlzLCBvciBub3Qgc3RvcmluZwo+IHRoZSBtYXN0ZXIga2V5IHNlY3VyZWx5IGFj cm9zcyByZWJvb3RzLgo+IAo+IE9uZSBhcHByb2FjaCBmb3Igc2VjdXJpbmcgdGhlIG1hc3RlciBr ZXkgd291bGQgYmUgdG8gZG8KPiB0aGF0IHVzaW5nIGEgVFBNIGFuZCB3aGlsZSBvbmUgY291bGQg bWFudWFsbHkgZG8gc28gZS5nLgo+IHVzaW5nIHRwbS10b29scywgdGhhdCBzdGlsbCBsZWF2ZXMg Y3JlYXRpb24gYW5kIGFjdHVhbAo+IGNvcnJlY3QgdXNhZ2Ugb2YgdHBtLXRvb2xzIHVwIHRvIHVz ZXItc3BhY2UsIHRob3VnaC4gQXMgYW4KPiBhc2lkZSwgdHBtLXRvb2xzIG5lZWRzIHRoZSB0Y3Nk IGRhZW1vbiBydW5uaW5nLCB3aGljaCBtYWtlcwo+IGl0IGF3a3dhcmQgdG8gdXNlIGZyb20gd2l0 aGluIGFuIGluaXRyYW1mcywgYW5kIHdoaWxlIG90aGVyCj4gbGlicmFyaWVzIGZvciBpbnRlcmZh Y2luZyB3aXRoIGEgVFBNIGRvIGV4aXN0LCB0aGVyZQo+IGFwcGVhcnMgdG8gYmUgYSBiZXR0ZXIg d2F5Ogo+IAo+IFRoZSBrZXJuZWwgYWxyZWFkeSBoYXMgYSBjb25jZXB0IG9mIHRydXN0ZWQgYXMg d2VsbCBhcwo+IGVuY3J5cHRlZCBrZXlzLiBUcnVzdGVkIGtleXMgYXJlIFRQTSBiYWNrZWQga2V5 cywgd2hpY2ggY2FuCj4gYmUgc2VhbGVkIHRvIFBDUnMgYW5kIGFsc28gZWFzaWx5IGJlIHJlLXNl YWxlZCBhZ2FpbnN0IG5ldwo+IGZ1dHVyZSBQQ1JzLCBhbmQgZW5jcnlwdGVkIGtleXMgYXJlIGtl eXMgdGhhdCBhcmUgZW5jcnlwdGVkCj4gdXNpbmcgYW5vdGhlciBrZXksIGUuZy4gYSB0cnVzdGVk IGtleS4gQWxsIGFyZSBnZW5lcmF0ZWQKPiBhdXRvbWF0aWNhbGx5IGJ5IHRoZSBrZXJuZWwgdXNp bmcgdGhlIFJORyBhbmQgbmV2ZXIgbGVhdmUKPiBrZXJuZWwgbWVtb3J5IHNwYWNlIChiYXIgYW55 IGtlcm5lbCBvciBoYXJkd2FyZSBidWdzKS4KClNheWluZyAidGhlIFJORyIgaXMgdW5jbGVhciwg c2luY2UgImVuY3J5cHRlZCIga2V5cyBhcmUgZ2VuZXJhdGVkIHVzaW5nIHRoZQprZXJuZWwncyBS Tkcgd2hlcmVhcyAidHJ1c3RlZCIga2V5cyBhcmUgZ2VuZXJhdGVkIHVzaW5nIHRoZSBUUE0ncyBS TkcuCgo+IAo+IFNvIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gYWxsb3cgdGhlIGZzY3J5cHQgc3Vi c3lzdGVtIHRvCj4gd29yayB3aXRoIGVuY3J5cHRlZCBrZXlzIGFzIHdlbGwuIFRoaXMgaXMgd2hh dCB0aGlzIGNoYW5nZQo+IGhlcmUgZG9lcy4KPiAKPiBXZSBjYW4gdXRpbGlzZSBrZXlzIHRoYXQg bmV2ZXIgZXZlciBleGlzdCBpbiB1c2VyLXNwYWNlLAo+IG5vdCBldmVuIGF0IGluaXRpYWwgY3Jl YXRpb24gdGltZSwgYXMgd2VsbCBhcyBzaW1wbGlmeWluZwo+IHVzYWdlIC8gY29uZmlndXJhdGlv bi4gU29tZXRoaW5nIHZlcnkgdmVyeSBzaW1pbGFyIGV4aXN0cwo+IGZvciBlQ3J5cHRzIGFscmVh ZHkuCgp0eXBvOiBlQ3J5cHRzID0+IGVDcnlwdGZzCgpbLi4uXQo+IGRpZmYgLS1naXQgYS9Eb2N1 bWVudGF0aW9uL2ZpbGVzeXN0ZW1zL2ZzY3J5cHQucnN0IGIvRG9jdW1lbnRhdGlvbi9maWxlc3lz dGVtcy9mc2NyeXB0LnJzdAo+IGluZGV4IDc3NmRkYzY1NWY3OS4uODUyYWMyOTAwYjY2IDEwMDY0 NAo+IC0tLSBhL0RvY3VtZW50YXRpb24vZmlsZXN5c3RlbXMvZnNjcnlwdC5yc3QKPiArKysgYi9E b2N1bWVudGF0aW9uL2ZpbGVzeXN0ZW1zL2ZzY3J5cHQucnN0Cj4gQEAgLTM2OCwxMSArMzY4LDE5 IEBAIEFkZGluZyBrZXlzCj4gIFRvIHByb3ZpZGUgYSBtYXN0ZXIga2V5LCB1c2Vyc3BhY2UgbXVz dCBhZGQgaXQgdG8gYW4gYXBwcm9wcmlhdGUKPiAga2V5cmluZyB1c2luZyB0aGUgYWRkX2tleSgp IHN5c3RlbSBjYWxsIChzZWU6Cj4gIGBgRG9jdW1lbnRhdGlvbi9zZWN1cml0eS9rZXlzL2NvcmUu cnN0YGApLiAgVGhlIGtleSB0eXBlIG11c3QgYmUKPiAtImxvZ29uIjsga2V5cyBvZiB0aGlzIHR5 cGUgYXJlIGtlcHQgaW4ga2VybmVsIG1lbW9yeSBhbmQgY2Fubm90IGJlCj4gLXJlYWQgYmFjayBi eSB1c2Vyc3BhY2UuICBUaGUga2V5IGRlc2NyaXB0aW9uIG11c3QgYmUgImZzY3J5cHQ6Igo+IC1m b2xsb3dlZCBieSB0aGUgMTYtY2hhcmFjdGVyIGxvd2VyIGNhc2UgaGV4IHJlcHJlc2VudGF0aW9u IG9mIHRoZQo+IC1gYG1hc3Rlcl9rZXlfZGVzY3JpcHRvcmBgIHRoYXQgd2FzIHNldCBpbiB0aGUg ZW5jcnlwdGlvbiBwb2xpY3kuICBUaGUKPiAta2V5IHBheWxvYWQgbXVzdCBjb25mb3JtIHRvIHRo ZSBmb2xsb3dpbmcgc3RydWN0dXJlOjoKPiArZWl0aGVyICJsb2dvbiIgb3IgImVuY3J5cHRlZCI7 ICJsb2dvbiIga2V5cyBhcmUga2VwdCBpbiBrZXJuZWwKPiArbWVtb3J5IGFuZCBjYW5ub3QgYmUg cmVhZCBiYWNrIGJ5IHVzZXJzcGFjZSB3aGlsZSAiZW5jcnlwdGVkIgo+ICtrZXlzIGNhbiBiZSBy b290ZWQgaW4gYSAidHJ1c3RlZCIga2V5IGFuZCB0aHVzIGFyZSBwcm90ZWN0ZWQgYnkKPiArYSBU UE0gYW5kIGNhbm5vdCBiZSByZWFkIGJ5IHVzZXJzcGFjZSBpbiB1bmVuY3J5cHRlZCBmb3JtLiBO b3RlCj4gK3RoYXQgd2hpbGUgYW4gImVuY3J5cHRlZCIga2V5IGNhbiBhbHNvIGJlIHJvb3RlZCBp biBhICJ1c2VyIiBrZXksCj4gK2FueSAiZW5jcnlwdGVkIiBrZXkgcm9vdGVkIGluIGEgInVzZXIi IGtleSBjYW4gZWZmZWN0aXZlbHkgYmUKPiArcmV0cmlldmVkIGluIHRoZSBjbGVhciwgaGVuY2Ug b25seSByb290aW5nIHRoZSBrZXkgaW4gYSAidHJ1c3RlZCIKPiAra2V5IGhhcyBhbnkgdXNlZnVs IHNlY3VyaXR5IHByb3BlcnRpZXMhCj4gKwo+ICtUaGUga2V5IGRlc2NyaXB0aW9uIG11c3QgYmUg ImZzY3J5cHQ6IiBmb2xsb3dlZCBieSB0aGUgMTYtY2hhcmFjdGVyCj4gK2xvd2VyIGNhc2UgaGV4 IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBgYG1hc3Rlcl9rZXlfZGVzY3JpcHRvcmBgIHRoYXQKPiAr d2FzIHNldCBpbiB0aGUgZW5jcnlwdGlvbiBwb2xpY3kuICBGb3IgYSAibG9nb24iIGtleSwga2V5 IHBheWxvYWQKPiArbXVzdCBjb25mb3JtIHRvIHRoZSBmb2xsb3dpbmcgc3RydWN0dXJlOjoKPiAg Cj4gICAgICAjZGVmaW5lIEZTX01BWF9LRVlfU0laRSA2NAo+ICAKPiBAQCAtMzg2LDYgKzM5NCwx NyBAQCBrZXkgcGF5bG9hZCBtdXN0IGNvbmZvcm0gdG8gdGhlIGZvbGxvd2luZyBzdHJ1Y3R1cmU6 Ogo+ICBgYHJhd2BgIHdpdGggYGBzaXplYGAgaW5kaWNhdGluZyBpdHMgc2l6ZSBpbiBieXRlcy4g IFRoYXQgaXMsIHRoZQo+ICBieXRlcyBgYHJhd1swLi5zaXplLTFdYGAgKGluY2x1c2l2ZSkgYXJl IHRoZSBhY3R1YWwga2V5Lgo+ICAKPiArV2hlbiB1c2luZyBhbiAiZW5jcnlwdGVkIiBrZXksIG9u bHkgdGhlIGFjdHVhbCBgYHJhd2BgIGtleSBmcm9tIGFib3ZlCj4gK2ZzY3J5cHRfa2V5IHN0cnVj dHVyZSBpcyBuZWVkZWQ6Ogo+ICsKPiArICAgIGtleWN0bCBhZGQgZW5jcnlwdGVkICJmc2NyeXB0 OmBgbWFzdGVyX2tleV9kZXNjcmlwdG9yYGAiICJuZXcgZGVmYXVsdCB0cnVzdGVkOmBgbWFzdGVy LWtleS1uYW1lYGAgYGBzaXplYGAiIGBgcmluZ2BgCj4gKyAgICBrZXljdGwgYWRkIGVuY3J5cHRl ZCAiZnNjcnlwdDpgYG1hc3Rlcl9rZXlfZGVzY3JpcHRvcmBgIiAibG9hZCBgYGhleF9ibG9iYGAi IGBgcmluZ2BgCj4gKwo+ICtXaGVyZTo6Cj4gKwo+ICsgICAgbWFzdGVyLWtleS1uYW1lOj0gbmFt ZSBvZiB0aGUgdHJ1c3RlZCBrZXkgdGhpcyBmc2NyeXB0IG1hc3RlciBrZXkKPiArICAgICAgICAg ICAgICAgICAgICAgIHNoYWxsIGJlIHJvb3RlZCBpbgo+ICsKCldlIG5lZWQgdG8gYmUgdmVyeSBj YXJlZnVsIHdpdGggdGhlIHdvcmRpbmcuICBGb3IgZXhhbXBsZSBpdCdzIGltcGxpZWQgdGhhdApl bmNyeXB0ZWQga2V5cyBjYW5ub3QgYmUgcmVhZCBieSB1c2Vyc3BhY2UgYmVjYXVzZSB0aGV5IGFy ZSBwcm90ZWN0ZWQgYnkgYSBUUE0sCmJ1dCB0aGF0J3Mgbm90IHRydWUuICBUaGV5IGNhbiBiZSAq d3JhcHBlZCogYnkgYSBrZXkgd2hpY2ggaW4gdHVybiBjYW4gYmUKVFBNLXNlYWxlZCwgYnV0IG9u Y2UgdW53cmFwcGVkIHRoZXkgYXJlIHByZXNlbnQgaW4gdGhlIGNsZWFyIGluIGtlcm5lbCBtZW1v cnksCmFuZCBpdCdzIG9ubHkgdGhlIHBvbGljeSBvZiB0aGUga2VybmVsIGNvZGUgdGhhdCB0aGV5 IGNhbid0IGJlIHJlYWQgYmFjayBpbiB0aGUKY2xlYXIuCgpBbHNvIHRoZSAibG9nb24iIGFuZCAi ZW5jcnlwdGVkIiBrZXkgdHlwZXMgc2hvdWxkIHByb2JhYmx5IGJlIGluIHRoZWlyIG93bgpzdWJz ZWN0aW9ucywgc28gdGhhdCB0aGVyZSBpcyBzcGFjZSB0byBleHBsYWluIHRoZW0gcHJvcGVybHku CgpJJ3ZlIHRyaWVkIHJlb3JnYW5pemluZyB0aGUgc2VjdGlvbiBhIGJpdCBhbmQgdGhpcyBpcyB3 aGF0IEkgY2FtZSB1cCB3aXRoOgoKQWRkaW5nIGtleXMKLS0tLS0tLS0tLS0KClRvIHByb3ZpZGUg YSBtYXN0ZXIga2V5LCB1c2Vyc3BhY2UgbXVzdCBhZGQgaXQgdG8gYW4gYXBwcm9wcmlhdGUKa2V5 cmluZyB1c2luZyB0aGUgYWRkX2tleSgpIHN5c3RlbSBjYWxsIChzZWU6CmBgRG9jdW1lbnRhdGlv bi9zZWN1cml0eS9rZXlzL2NvcmUucnN0YGApLgoKVGhlIGtleSBkZXNjcmlwdGlvbiBtdXN0IGJl ICJmc2NyeXB0OiIgZm9sbG93ZWQgYnkgdGhlIDE2LWNoYXJhY3Rlcgpsb3dlciBjYXNlIGhleCBy ZXByZXNlbnRhdGlvbiBvZiB0aGUgYGBtYXN0ZXJfa2V5X2Rlc2NyaXB0b3JgYCB0aGF0CndhcyBz ZXQgaW4gdGhlIGVuY3J5cHRpb24gcG9saWN5LiAgVGhlICJmc2NyeXB0OiIgcHJlZml4IGNhbgph bHRlcm5hdGl2ZWx5IGJlIHJlcGxhY2VkIHdpdGggYSBmaWxlc3lzdGVtLXNwZWNpZmljIHByZWZp eCBzdWNoIGFzCiJleHQ0OiIuICBIb3dldmVyLCB0aGUgZmlsZXN5c3RlbS1zcGVjaWZpYyBwcmVm aXhlcyBhcmUgZGVwcmVjYXRlZCBhbmQKc2hvdWxkIG5vdCBiZSB1c2VkIGluIG5ldyBwcm9ncmFt cy4KClRoZSBrZXkgdHlwZSBtdXN0IGJlICJsb2dvbiIgb3IgImVuY3J5cHRlZCIsIGFzIGRlc2Ny aWJlZCBiZWxvdy4KU3VwcG9ydCBmb3IgdGhlICJsb2dvbiIga2V5IHR5cGUgd2lsbCBhbHdheXMg YmUgYXZhaWxhYmxlIHdoZW4gYW55CmZpbGVzeXN0ZW0gaGFzIGZzY3J5cHQgc3VwcG9ydCBlbmFi bGVkLCB3aGVyZWFzIHN1cHBvcnQgZm9yIHRoZQoiZW5jcnlwdGVkIiBrZXkgdHlwZSBhZGRpdGlv bmFsbHkgcmVxdWlyZXMgQ09ORklHX0VOQ1JZUFRFRF9LRVlTPXkuCgpMb2dvbiBrZXkgdHlwZQp+ fn5+fn5+fn5+fn5+fgoKV2l0aCB0aGUgImxvZ29uIiB0eXBlLCB1c2Vyc3BhY2UgaXMgcmVzcG9u c2libGUgZm9yIGdlbmVyYXRpbmcgb3IKdW53cmFwcGluZyB0aGUgbWFzdGVyIGtleSwgdGhlbiBw YXNzaW5nIGl0IHRvIHRoZSBrZXJuZWwgaW4gdGhlCmZvbGxvd2luZyBmb3JtYXQ6CgogICAgI2Rl ZmluZSBGU19NQVhfS0VZX1NJWkUgNjQKCiAgICBzdHJ1Y3QgZnNjcnlwdF9rZXkgewogICAgICAg ICAgICB1MzIgbW9kZTsKICAgICAgICAgICAgdTggcmF3W0ZTX01BWF9LRVlfU0laRV07CiAgICAg ICAgICAgIHUzMiBzaXplOwogICAgfTsKCmBgbW9kZWBgIGlzIGlnbm9yZWQ7IGp1c3Qgc2V0IGl0 IHRvIDAuICBUaGUgYWN0dWFsIGtleSBpcyBwcm92aWRlZCBpbgpgYHJhd2BgIHdpdGggYGBzaXpl YGAgaW5kaWNhdGluZyBpdHMgc2l6ZSBpbiBieXRlcy4gIFRoYXQgaXMsIHRoZQpieXRlcyBgYHJh d1swLi5zaXplLTFdYGAgKGluY2x1c2l2ZSkgYXJlIHRoZSBhY3R1YWwga2V5LgoKVGhlICJsb2dv biIga2V5IHdpbGwgdGhlbiBiZSBzdG9yZWQgaW4ga2VybmVsIG1lbW9yeSBmb3IgdGhlCmZpbGVz eXN0ZW0gdG8gdXNlLiAgVGhlcmUgaXMgbm8gQVBJIGZvciB1c2Vyc3BhY2UgdG8gcmVhZCBpdCBi YWNrLgoKRW5jcnlwdGVkIGtleSB0eXBlCn5+fn5+fn5+fn5+fn5+fn5+fgoKV2l0aCB0aGUgImVu Y3J5cHRlZCIga2V5IHR5cGUsIHRoZSBrZXkgaXMgaW5pdGlhbGx5IHJhbmRvbWx5IGdlbmVyYXRl ZApieSB0aGUga2VybmVsLiAgVGhlbiwgdXNlcnNwYWNlIGNhbiByZWFkIGl0IGJhY2sgYXMgYSBi bG9iIHdyYXBwZWQgYnkKYW5vdGhlciBrZXkuICBJbiBwYXJ0aWN1bGFyLCBpdCBjYW4gYmUgd3Jh cHBlZCBieSBhICJ0cnVzdGVkIiBrZXksCndoaWNoIGNhbiBiZSBzZWFsZWQgdG8gYSBUUE0gaW4g YSBjZXJ0YWluIHN0YXRlLCB3aXRoIG9ubHkgdGhlClRQTS1zZWFsZWQgYmxvYiBiZWluZyBtYWRl IGF2YWlsYWJsZSB0byB1c2Vyc3BhY2UuICBUaGVuLCB1c2Vyc3BhY2UKY2FuIGxhdGVyIHJlLWlu c3RhbnRpYXRlIHRoZSAiZW5jcnlwdGVkIiBrZXkgYnkgZmlyc3QgcmUtaW5zdGFudGlhdGluZwp0 aGUgbmVlZGVkICJ0cnVzdGVkIiBrZXksIHRoZW4gcHJvdmlkaW5nIHRoZSBlbmNyeXB0ZWQta2V5 IGJsb2IgdG8gYmUKdW53cmFwcGVkIGJ5IHRoZSBrZXJuZWwuICBGb3IgZXhhbXBsZToKCiAgICAj IGNyZWF0ZSBhIG5ldyBlbmNyeXB0ZWQta2V5CiAgICBrZXljdGwgYWRkIGVuY3J5cHRlZCAiZnNj cnlwdDpgYG1hc3Rlcl9rZXlfZGVzY3JpcHRvcmBgIiAibmV3IGRlZmF1bHQgdHJ1c3RlZDpgYG1h c3Rlci1rZXktZGVzY2BgIGBgc2l6ZWBgIiBgYHJpbmdgYAoKICAgICMgdW53cmFwIGFuIGV4aXN0 aW5nIGVuY3J5cHRlZC1rZXkgYmxvYgogICAga2V5Y3RsIGFkZCBlbmNyeXB0ZWQgImZzY3J5cHQ6 YGBtYXN0ZXJfa2V5X2Rlc2NyaXB0b3JgYCIgImxvYWQgYGBoZXhfYmxvYmBgIiBgYHJpbmdgYAoK V2hlcmU6OgoKICAgIG1hc3Rlci1rZXktZGVzYzo9IGRlc2NyaXB0aW9uIG9mIHRoZSB0cnVzdGVk IGtleSB0aGlzIGZzY3J5cHQgbWFzdGVyIGtleQogICAgICAgICAgICAgICAgICAgICAgc2hhbGwg YmUgd3JhcHBlZCBieQoKICAgIHNpemUgOj0gZGVzaXJlZCBzaXplIG9mIHRoZSBmc2NyeXB0IG1h c3RlciBrZXkgaW4gYnl0ZXMKCiAgICByaW5nIDo9IGtleXJpbmcgdG8gYWRkIHRoZSBrZXkgdG8K ClRoZSAiZW5jcnlwdGVkIiBrZXkgbXVzdCBiZSBpbnN0YW50aWF0ZWQgdXNpbmcgdGhlICJkZWZh dWx0IiBmb3JtYXQsCnNpbmNlIGl0cyBkZWNyeXB0ZWQgcGF5bG9hZCBpcyB0cmVhdGVkIGFzIHRo ZSByYXcgbWFzdGVyIGtleTsgdGhhdCBpcywKdGhlIGBgZnNjcnlwdF9rZXlgYCBzdHJ1Y3R1cmUg aXMgbm90IHVzZWQuCgpOb3RlIHRoYXQganVzdCBsaWtlICJsb2dvbiIga2V5cywgImVuY3J5cHRl ZCIga2V5cyBhcmUgYWN0dWFsbHkKcHJlc2VudCBpbiBrZXJuZWwgbWVtb3J5IGluIHRoZSBjbGVh ciBhZnRlciBiZWluZyBhZGRlZC4gIFRodXMsIHRoZXkKYXJlIG5vdCBzYWZlIGZyb20gYXR0YWNr cyB0aGF0IGNvbXByb21pc2Uga2VybmVsIG1lbW9yeS4gIEhvd2V2ZXIsCnRoZXkgY2Fubm90IGJl IHJlYWQgYmFjayBpbiB0aGUgY2xlYXIgdXNpbmcgdGhlIHN5c3RlbSBjYWxsIGludGVyZmFjZS4K CkNob2ljZSBvZiBrZXlyaW5nCn5+fn5+fn5+fn5+fn5+fn5+CgpUaGVyZSBhcmUgc2V2ZXJhbCBk aWZmZXJlbnQgdHlwZXMgb2Yga2V5cmluZ3MgaW4gd2hpY2ggZnNjcnlwdCBtYXN0ZXIKa2V5cyBt YXkgYmUgcGxhY2VkLCBzdWNoIGFzIGEgc2Vzc2lvbiBrZXlyaW5nLCBhIHVzZXIgc2Vzc2lvbiBr ZXlyaW5nLApvciBhIHVzZXIga2V5cmluZy4gIEVhY2gga2V5IG11c3QgYmUgcGxhY2VkIGluIGEg a2V5cmluZyB0aGF0IGlzCiJhdHRhY2hlZCIgdG8gYWxsIHByb2Nlc3NlcyB0aGF0IG1pZ2h0IG5l ZWQgdG8gYWNjZXNzIGZpbGVzIGVuY3J5cHRlZAp3aXRoIGl0LCBpbiB0aGUgc2Vuc2UgdGhhdCBy ZXF1ZXN0X2tleSgpIHdpbGwgZmluZCB0aGUga2V5LgpHZW5lcmFsbHksIGlmIG9ubHkgcHJvY2Vz c2VzIGJlbG9uZ2luZyB0byBhIHNwZWNpZmljIHVzZXIgbmVlZCB0bwphY2Nlc3MgYSBnaXZlbiBl bmNyeXB0ZWQgZGlyZWN0b3J5IGFuZCBubyBzZXNzaW9uIGtleXJpbmcgaGFzIGJlZW4KaW5zdGFs bGVkLCB0aGVuIHRoYXQgZGlyZWN0b3J5J3Mga2V5IHNob3VsZCBiZSBwbGFjZWQgaW4gdGhhdCB1 c2VyJ3MKdXNlciBzZXNzaW9uIGtleXJpbmcgb3IgdXNlciBrZXlyaW5nLiAgT3RoZXJ3aXNlLCBh IHNlc3Npb24ga2V5cmluZwpzaG91bGQgYmUgaW5zdGFsbGVkIGlmIG5lZWRlZCwgYW5kIHRoZSBr ZXkgc2hvdWxkIGJlIGxpbmtlZCBpbnRvIHRoYXQKc2Vzc2lvbiBrZXlyaW5nLCBvciBpbiBhIGtl eXJpbmcgbGlua2VkIGludG8gdGhhdCBzZXNzaW9uIGtleXJpbmcuCgpOb3RlOiBpbnRyb2R1Y2lu ZyB0aGUgY29tcGxleCB2aXNpYmlsaXR5IHNlbWFudGljcyBvZiBrZXlyaW5ncyBoZXJlCndhcyBh cmd1YWJseSBhIG1pc3Rha2UgLS0tIGVzcGVjaWFsbHkgZ2l2ZW4gdGhhdCBieSBkZXNpZ24sIGFm dGVyIGFueQpwcm9jZXNzIHN1Y2Nlc3NmdWxseSBvcGVucyBhbiBlbmNyeXB0ZWQgZmlsZSAodGhl cmVieSBzZXR0aW5nIHVwIHRoZQpwZXItZmlsZSBrZXkpLCBwb3NzZXNzaW5nIHRoZSBrZXlyaW5n IGtleSBpcyBub3QgYWN0dWFsbHkgcmVxdWlyZWQgZm9yCmFueSBwcm9jZXNzIHRvIHJlYWQvd3Jp dGUgdGhlIGZpbGUgdW50aWwgaXRzIGluLW1lbW9yeSBpbm9kZSBpcwpldmljdGVkLiAgSW4gdGhl IGZ1dHVyZSB0aGVyZSBwcm9iYWJseSBzaG91bGQgYmUgYSB3YXkgdG8gcHJvdmlkZSBrZXlzCmRp cmVjdGx5IHRvIHRoZSBmaWxlc3lzdGVtIGluc3RlYWQsIHdoaWNoIHdvdWxkIG1ha2UgdGhlIGlu dGVuZGVkCnNlbWFudGljcyBjbGVhcmVyLgotLQpUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlz dDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUga2V5cmluZ3MiIGluCnRoZSBib2R5IG9mIGEg bWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3JnCk1vcmUgbWFqb3Jkb21vIGluZm8g YXQgIGh0dHA6Ly92Z2VyLmtlcm5lbC5vcmcvbWFqb3Jkb21vLWluZm8uaHRtbA== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 25 Jan 2018 16:36:48 -0800 From: Eric Biggers Subject: Re: [PATCH v3] fscrypt: add support for the encrypted key type Message-ID: <20180126003648.jtmiznczkinla353@gmail.com> References: <20180118131359.8365-1-git@andred.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180118131359.8365-1-git@andred.net> To: =?iso-8859-1?Q?Andr=E9?= Draszik Cc: linux-kernel@vger.kernel.org, Mimi Zohar , David Howells , James Morris , "Serge E. Hallyn" , "Theodore Y. Ts'o" , Jaegeuk Kim , Kees Cook , Eric Biggers , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org List-ID: On Thu, Jan 18, 2018 at 01:13:59PM +0000, Andr� Draszik wrote: > fscrypt uses a master key for each directory policy from > which all further keys for that policy are derived, and > at the moment such a master key has to be inserted into > a kernel keyring as a 'logon' key by user-space. > > While 'logon' keys have the nice property of not being > readable by user-space (keyctl dump etc.), the fscrypt There is no 'keyctl dump' command. Probably you meant 'keyctl read'. > master key still needs to be generated initially, in a > secure way, and it needs to be saved somewhere for > subsequent reboots, and hence also needs securing itself. > > Usage of the 'logon' key means that it is up to user-space > to do all that, opening up the possibility of creating > cryptographically non-sound master keys, or not storing > the master key securely across reboots. > > One approach for securing the master key would be to do > that using a TPM and while one could manually do so e.g. > using tpm-tools, that still leaves creation and actual > correct usage of tpm-tools up to user-space, though. As an > aside, tpm-tools needs the tcsd daemon running, which makes > it awkward to use from within an initramfs, and while other > libraries for interfacing with a TPM do exist, there > appears to be a better way: > > The kernel already has a concept of trusted as well as > encrypted keys. Trusted keys are TPM backed keys, which can > be sealed to PCRs and also easily be re-sealed against new > future PCRs, and encrypted keys are keys that are encrypted > using another key, e.g. a trusted key. All are generated > automatically by the kernel using the RNG and never leave > kernel memory space (bar any kernel or hardware bugs). Saying "the RNG" is unclear, since "encrypted" keys are generated using the kernel's RNG whereas "trusted" keys are generated using the TPM's RNG. > > So it seems reasonable to allow the fscrypt subsystem to > work with encrypted keys as well. This is what this change > here does. > > We can utilise keys that never ever exist in user-space, > not even at initial creation time, as well as simplifying > usage / configuration. Something very very similar exists > for eCrypts already. typo: eCrypts => eCryptfs [...] > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index 776ddc655f79..852ac2900b66 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -368,11 +368,19 @@ Adding keys > To provide a master key, userspace must add it to an appropriate > keyring using the add_key() system call (see: > ``Documentation/security/keys/core.rst``). The key type must be > -"logon"; keys of this type are kept in kernel memory and cannot be > -read back by userspace. The key description must be "fscrypt:" > -followed by the 16-character lower case hex representation of the > -``master_key_descriptor`` that was set in the encryption policy. The > -key payload must conform to the following structure:: > +either "logon" or "encrypted"; "logon" keys are kept in kernel > +memory and cannot be read back by userspace while "encrypted" > +keys can be rooted in a "trusted" key and thus are protected by > +a TPM and cannot be read by userspace in unencrypted form. Note > +that while an "encrypted" key can also be rooted in a "user" key, > +any "encrypted" key rooted in a "user" key can effectively be > +retrieved in the clear, hence only rooting the key in a "trusted" > +key has any useful security properties! > + > +The key description must be "fscrypt:" followed by the 16-character > +lower case hex representation of the ``master_key_descriptor`` that > +was set in the encryption policy. For a "logon" key, key payload > +must conform to the following structure:: > > #define FS_MAX_KEY_SIZE 64 > > @@ -386,6 +394,17 @@ key payload must conform to the following structure:: > ``raw`` with ``size`` indicating its size in bytes. That is, the > bytes ``raw[0..size-1]`` (inclusive) are the actual key. > > +When using an "encrypted" key, only the actual ``raw`` key from above > +fscrypt_key structure is needed:: > + > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-name`` ``size``" ``ring`` > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` > + > +Where:: > + > + master-key-name:= name of the trusted key this fscrypt master key > + shall be rooted in > + We need to be very careful with the wording. For example it's implied that encrypted keys cannot be read by userspace because they are protected by a TPM, but that's not true. They can be *wrapped* by a key which in turn can be TPM-sealed, but once unwrapped they are present in the clear in kernel memory, and it's only the policy of the kernel code that they can't be read back in the clear. Also the "logon" and "encrypted" key types should probably be in their own subsections, so that there is space to explain them properly. I've tried reorganizing the section a bit and this is what I came up with: Adding keys ----------- To provide a master key, userspace must add it to an appropriate keyring using the add_key() system call (see: ``Documentation/security/keys/core.rst``). The key description must be "fscrypt:" followed by the 16-character lower case hex representation of the ``master_key_descriptor`` that was set in the encryption policy. The "fscrypt:" prefix can alternatively be replaced with a filesystem-specific prefix such as "ext4:". However, the filesystem-specific prefixes are deprecated and should not be used in new programs. The key type must be "logon" or "encrypted", as described below. Support for the "logon" key type will always be available when any filesystem has fscrypt support enabled, whereas support for the "encrypted" key type additionally requires CONFIG_ENCRYPTED_KEYS=y. Logon key type ~~~~~~~~~~~~~~ With the "logon" type, userspace is responsible for generating or unwrapping the master key, then passing it to the kernel in the following format: #define FS_MAX_KEY_SIZE 64 struct fscrypt_key { u32 mode; u8 raw[FS_MAX_KEY_SIZE]; u32 size; }; ``mode`` is ignored; just set it to 0. The actual key is provided in ``raw`` with ``size`` indicating its size in bytes. That is, the bytes ``raw[0..size-1]`` (inclusive) are the actual key. The "logon" key will then be stored in kernel memory for the filesystem to use. There is no API for userspace to read it back. Encrypted key type ~~~~~~~~~~~~~~~~~~ With the "encrypted" key type, the key is initially randomly generated by the kernel. Then, userspace can read it back as a blob wrapped by another key. In particular, it can be wrapped by a "trusted" key, which can be sealed to a TPM in a certain state, with only the TPM-sealed blob being made available to userspace. Then, userspace can later re-instantiate the "encrypted" key by first re-instantiating the needed "trusted" key, then providing the encrypted-key blob to be unwrapped by the kernel. For example: # create a new encrypted-key keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-desc`` ``size``" ``ring`` # unwrap an existing encrypted-key blob keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` Where:: master-key-desc:= description of the trusted key this fscrypt master key shall be wrapped by size := desired size of the fscrypt master key in bytes ring := keyring to add the key to The "encrypted" key must be instantiated using the "default" format, since its decrypted payload is treated as the raw master key; that is, the ``fscrypt_key`` structure is not used. Note that just like "logon" keys, "encrypted" keys are actually present in kernel memory in the clear after being added. Thus, they are not safe from attacks that compromise kernel memory. However, they cannot be read back in the clear using the system call interface. Choice of keyring ~~~~~~~~~~~~~~~~~ There are several different types of keyrings in which fscrypt master keys may be placed, such as a session keyring, a user session keyring, or a user keyring. Each key must be placed in a keyring that is "attached" to all processes that might need to access files encrypted with it, in the sense that request_key() will find the key. Generally, if only processes belonging to a specific user need to access a given encrypted directory and no session keyring has been installed, then that directory's key should be placed in that user's user session keyring or user keyring. Otherwise, a session keyring should be installed if needed, and the key should be linked into that session keyring, or in a keyring linked into that session keyring. Note: introducing the complex visibility semantics of keyrings here was arguably a mistake --- especially given that by design, after any process successfully opens an encrypted file (thereby setting up the per-file key), possessing the keyring key is not actually required for any process to read/write the file until its in-memory inode is evicted. In the future there probably should be a way to provide keys directly to the filesystem instead, which would make the intended semantics clearer. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f182.google.com ([209.85.223.182]:40385 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbeAZAgw (ORCPT ); Thu, 25 Jan 2018 19:36:52 -0500 Date: Thu, 25 Jan 2018 16:36:48 -0800 From: Eric Biggers To: =?iso-8859-1?Q?Andr=E9?= Draszik Cc: linux-kernel@vger.kernel.org, Mimi Zohar , David Howells , James Morris , "Serge E. Hallyn" , "Theodore Y. Ts'o" , Jaegeuk Kim , Kees Cook , Eric Biggers , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org Subject: Re: [PATCH v3] fscrypt: add support for the encrypted key type Message-ID: <20180126003648.jtmiznczkinla353@gmail.com> References: <20180118131359.8365-1-git@andred.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 In-Reply-To: <20180118131359.8365-1-git@andred.net> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Thu, Jan 18, 2018 at 01:13:59PM +0000, Andre Draszik wrote: > fscrypt uses a master key for each directory policy from > which all further keys for that policy are derived, and > at the moment such a master key has to be inserted into > a kernel keyring as a 'logon' key by user-space. > > While 'logon' keys have the nice property of not being > readable by user-space (keyctl dump etc.), the fscrypt There is no 'keyctl dump' command. Probably you meant 'keyctl read'. > master key still needs to be generated initially, in a > secure way, and it needs to be saved somewhere for > subsequent reboots, and hence also needs securing itself. > > Usage of the 'logon' key means that it is up to user-space > to do all that, opening up the possibility of creating > cryptographically non-sound master keys, or not storing > the master key securely across reboots. > > One approach for securing the master key would be to do > that using a TPM and while one could manually do so e.g. > using tpm-tools, that still leaves creation and actual > correct usage of tpm-tools up to user-space, though. As an > aside, tpm-tools needs the tcsd daemon running, which makes > it awkward to use from within an initramfs, and while other > libraries for interfacing with a TPM do exist, there > appears to be a better way: > > The kernel already has a concept of trusted as well as > encrypted keys. Trusted keys are TPM backed keys, which can > be sealed to PCRs and also easily be re-sealed against new > future PCRs, and encrypted keys are keys that are encrypted > using another key, e.g. a trusted key. All are generated > automatically by the kernel using the RNG and never leave > kernel memory space (bar any kernel or hardware bugs). Saying "the RNG" is unclear, since "encrypted" keys are generated using the kernel's RNG whereas "trusted" keys are generated using the TPM's RNG. > > So it seems reasonable to allow the fscrypt subsystem to > work with encrypted keys as well. This is what this change > here does. > > We can utilise keys that never ever exist in user-space, > not even at initial creation time, as well as simplifying > usage / configuration. Something very very similar exists > for eCrypts already. typo: eCrypts => eCryptfs [...] > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index 776ddc655f79..852ac2900b66 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -368,11 +368,19 @@ Adding keys > To provide a master key, userspace must add it to an appropriate > keyring using the add_key() system call (see: > ``Documentation/security/keys/core.rst``). The key type must be > -"logon"; keys of this type are kept in kernel memory and cannot be > -read back by userspace. The key description must be "fscrypt:" > -followed by the 16-character lower case hex representation of the > -``master_key_descriptor`` that was set in the encryption policy. The > -key payload must conform to the following structure:: > +either "logon" or "encrypted"; "logon" keys are kept in kernel > +memory and cannot be read back by userspace while "encrypted" > +keys can be rooted in a "trusted" key and thus are protected by > +a TPM and cannot be read by userspace in unencrypted form. Note > +that while an "encrypted" key can also be rooted in a "user" key, > +any "encrypted" key rooted in a "user" key can effectively be > +retrieved in the clear, hence only rooting the key in a "trusted" > +key has any useful security properties! > + > +The key description must be "fscrypt:" followed by the 16-character > +lower case hex representation of the ``master_key_descriptor`` that > +was set in the encryption policy. For a "logon" key, key payload > +must conform to the following structure:: > > #define FS_MAX_KEY_SIZE 64 > > @@ -386,6 +394,17 @@ key payload must conform to the following structure:: > ``raw`` with ``size`` indicating its size in bytes. That is, the > bytes ``raw[0..size-1]`` (inclusive) are the actual key. > > +When using an "encrypted" key, only the actual ``raw`` key from above > +fscrypt_key structure is needed:: > + > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-name`` ``size``" ``ring`` > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` > + > +Where:: > + > + master-key-name:= name of the trusted key this fscrypt master key > + shall be rooted in > + We need to be very careful with the wording. For example it's implied that encrypted keys cannot be read by userspace because they are protected by a TPM, but that's not true. They can be *wrapped* by a key which in turn can be TPM-sealed, but once unwrapped they are present in the clear in kernel memory, and it's only the policy of the kernel code that they can't be read back in the clear. Also the "logon" and "encrypted" key types should probably be in their own subsections, so that there is space to explain them properly. I've tried reorganizing the section a bit and this is what I came up with: Adding keys ----------- To provide a master key, userspace must add it to an appropriate keyring using the add_key() system call (see: ``Documentation/security/keys/core.rst``). The key description must be "fscrypt:" followed by the 16-character lower case hex representation of the ``master_key_descriptor`` that was set in the encryption policy. The "fscrypt:" prefix can alternatively be replaced with a filesystem-specific prefix such as "ext4:". However, the filesystem-specific prefixes are deprecated and should not be used in new programs. The key type must be "logon" or "encrypted", as described below. Support for the "logon" key type will always be available when any filesystem has fscrypt support enabled, whereas support for the "encrypted" key type additionally requires CONFIG_ENCRYPTED_KEYS=y. Logon key type ~~~~~~~~~~~~~~ With the "logon" type, userspace is responsible for generating or unwrapping the master key, then passing it to the kernel in the following format: #define FS_MAX_KEY_SIZE 64 struct fscrypt_key { u32 mode; u8 raw[FS_MAX_KEY_SIZE]; u32 size; }; ``mode`` is ignored; just set it to 0. The actual key is provided in ``raw`` with ``size`` indicating its size in bytes. That is, the bytes ``raw[0..size-1]`` (inclusive) are the actual key. The "logon" key will then be stored in kernel memory for the filesystem to use. There is no API for userspace to read it back. Encrypted key type ~~~~~~~~~~~~~~~~~~ With the "encrypted" key type, the key is initially randomly generated by the kernel. Then, userspace can read it back as a blob wrapped by another key. In particular, it can be wrapped by a "trusted" key, which can be sealed to a TPM in a certain state, with only the TPM-sealed blob being made available to userspace. Then, userspace can later re-instantiate the "encrypted" key by first re-instantiating the needed "trusted" key, then providing the encrypted-key blob to be unwrapped by the kernel. For example: # create a new encrypted-key keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-desc`` ``size``" ``ring`` # unwrap an existing encrypted-key blob keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` Where:: master-key-desc:= description of the trusted key this fscrypt master key shall be wrapped by size := desired size of the fscrypt master key in bytes ring := keyring to add the key to The "encrypted" key must be instantiated using the "default" format, since its decrypted payload is treated as the raw master key; that is, the ``fscrypt_key`` structure is not used. Note that just like "logon" keys, "encrypted" keys are actually present in kernel memory in the clear after being added. Thus, they are not safe from attacks that compromise kernel memory. However, they cannot be read back in the clear using the system call interface. Choice of keyring ~~~~~~~~~~~~~~~~~ There are several different types of keyrings in which fscrypt master keys may be placed, such as a session keyring, a user session keyring, or a user keyring. Each key must be placed in a keyring that is "attached" to all processes that might need to access files encrypted with it, in the sense that request_key() will find the key. Generally, if only processes belonging to a specific user need to access a given encrypted directory and no session keyring has been installed, then that directory's key should be placed in that user's user session keyring or user keyring. Otherwise, a session keyring should be installed if needed, and the key should be linked into that session keyring, or in a keyring linked into that session keyring. Note: introducing the complex visibility semantics of keyrings here was arguably a mistake --- especially given that by design, after any process successfully opens an encrypted file (thereby setting up the per-file key), possessing the keyring key is not actually required for any process to read/write the file until its in-memory inode is evicted. In the future there probably should be a way to provide keys directly to the filesystem instead, which would make the intended semantics clearer. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiggers3@gmail.com (Eric Biggers) Date: Thu, 25 Jan 2018 16:36:48 -0800 Subject: [PATCH v3] fscrypt: add support for the encrypted key type In-Reply-To: <20180118131359.8365-1-git@andred.net> References: <20180118131359.8365-1-git@andred.net> Message-ID: <20180126003648.jtmiznczkinla353@gmail.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Thu, Jan 18, 2018 at 01:13:59PM +0000, Andr? Draszik wrote: > fscrypt uses a master key for each directory policy from > which all further keys for that policy are derived, and > at the moment such a master key has to be inserted into > a kernel keyring as a 'logon' key by user-space. > > While 'logon' keys have the nice property of not being > readable by user-space (keyctl dump etc.), the fscrypt There is no 'keyctl dump' command. Probably you meant 'keyctl read'. > master key still needs to be generated initially, in a > secure way, and it needs to be saved somewhere for > subsequent reboots, and hence also needs securing itself. > > Usage of the 'logon' key means that it is up to user-space > to do all that, opening up the possibility of creating > cryptographically non-sound master keys, or not storing > the master key securely across reboots. > > One approach for securing the master key would be to do > that using a TPM and while one could manually do so e.g. > using tpm-tools, that still leaves creation and actual > correct usage of tpm-tools up to user-space, though. As an > aside, tpm-tools needs the tcsd daemon running, which makes > it awkward to use from within an initramfs, and while other > libraries for interfacing with a TPM do exist, there > appears to be a better way: > > The kernel already has a concept of trusted as well as > encrypted keys. Trusted keys are TPM backed keys, which can > be sealed to PCRs and also easily be re-sealed against new > future PCRs, and encrypted keys are keys that are encrypted > using another key, e.g. a trusted key. All are generated > automatically by the kernel using the RNG and never leave > kernel memory space (bar any kernel or hardware bugs). Saying "the RNG" is unclear, since "encrypted" keys are generated using the kernel's RNG whereas "trusted" keys are generated using the TPM's RNG. > > So it seems reasonable to allow the fscrypt subsystem to > work with encrypted keys as well. This is what this change > here does. > > We can utilise keys that never ever exist in user-space, > not even at initial creation time, as well as simplifying > usage / configuration. Something very very similar exists > for eCrypts already. typo: eCrypts => eCryptfs [...] > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index 776ddc655f79..852ac2900b66 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -368,11 +368,19 @@ Adding keys > To provide a master key, userspace must add it to an appropriate > keyring using the add_key() system call (see: > ``Documentation/security/keys/core.rst``). The key type must be > -"logon"; keys of this type are kept in kernel memory and cannot be > -read back by userspace. The key description must be "fscrypt:" > -followed by the 16-character lower case hex representation of the > -``master_key_descriptor`` that was set in the encryption policy. The > -key payload must conform to the following structure:: > +either "logon" or "encrypted"; "logon" keys are kept in kernel > +memory and cannot be read back by userspace while "encrypted" > +keys can be rooted in a "trusted" key and thus are protected by > +a TPM and cannot be read by userspace in unencrypted form. Note > +that while an "encrypted" key can also be rooted in a "user" key, > +any "encrypted" key rooted in a "user" key can effectively be > +retrieved in the clear, hence only rooting the key in a "trusted" > +key has any useful security properties! > + > +The key description must be "fscrypt:" followed by the 16-character > +lower case hex representation of the ``master_key_descriptor`` that > +was set in the encryption policy. For a "logon" key, key payload > +must conform to the following structure:: > > #define FS_MAX_KEY_SIZE 64 > > @@ -386,6 +394,17 @@ key payload must conform to the following structure:: > ``raw`` with ``size`` indicating its size in bytes. That is, the > bytes ``raw[0..size-1]`` (inclusive) are the actual key. > > +When using an "encrypted" key, only the actual ``raw`` key from above > +fscrypt_key structure is needed:: > + > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-name`` ``size``" ``ring`` > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` > + > +Where:: > + > + master-key-name:= name of the trusted key this fscrypt master key > + shall be rooted in > + We need to be very careful with the wording. For example it's implied that encrypted keys cannot be read by userspace because they are protected by a TPM, but that's not true. They can be *wrapped* by a key which in turn can be TPM-sealed, but once unwrapped they are present in the clear in kernel memory, and it's only the policy of the kernel code that they can't be read back in the clear. Also the "logon" and "encrypted" key types should probably be in their own subsections, so that there is space to explain them properly. I've tried reorganizing the section a bit and this is what I came up with: Adding keys ----------- To provide a master key, userspace must add it to an appropriate keyring using the add_key() system call (see: ``Documentation/security/keys/core.rst``). The key description must be "fscrypt:" followed by the 16-character lower case hex representation of the ``master_key_descriptor`` that was set in the encryption policy. The "fscrypt:" prefix can alternatively be replaced with a filesystem-specific prefix such as "ext4:". However, the filesystem-specific prefixes are deprecated and should not be used in new programs. The key type must be "logon" or "encrypted", as described below. Support for the "logon" key type will always be available when any filesystem has fscrypt support enabled, whereas support for the "encrypted" key type additionally requires CONFIG_ENCRYPTED_KEYS=y. Logon key type ~~~~~~~~~~~~~~ With the "logon" type, userspace is responsible for generating or unwrapping the master key, then passing it to the kernel in the following format: #define FS_MAX_KEY_SIZE 64 struct fscrypt_key { u32 mode; u8 raw[FS_MAX_KEY_SIZE]; u32 size; }; ``mode`` is ignored; just set it to 0. The actual key is provided in ``raw`` with ``size`` indicating its size in bytes. That is, the bytes ``raw[0..size-1]`` (inclusive) are the actual key. The "logon" key will then be stored in kernel memory for the filesystem to use. There is no API for userspace to read it back. Encrypted key type ~~~~~~~~~~~~~~~~~~ With the "encrypted" key type, the key is initially randomly generated by the kernel. Then, userspace can read it back as a blob wrapped by another key. In particular, it can be wrapped by a "trusted" key, which can be sealed to a TPM in a certain state, with only the TPM-sealed blob being made available to userspace. Then, userspace can later re-instantiate the "encrypted" key by first re-instantiating the needed "trusted" key, then providing the encrypted-key blob to be unwrapped by the kernel. For example: # create a new encrypted-key keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-desc`` ``size``" ``ring`` # unwrap an existing encrypted-key blob keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` Where:: master-key-desc:= description of the trusted key this fscrypt master key shall be wrapped by size := desired size of the fscrypt master key in bytes ring := keyring to add the key to The "encrypted" key must be instantiated using the "default" format, since its decrypted payload is treated as the raw master key; that is, the ``fscrypt_key`` structure is not used. Note that just like "logon" keys, "encrypted" keys are actually present in kernel memory in the clear after being added. Thus, they are not safe from attacks that compromise kernel memory. However, they cannot be read back in the clear using the system call interface. Choice of keyring ~~~~~~~~~~~~~~~~~ There are several different types of keyrings in which fscrypt master keys may be placed, such as a session keyring, a user session keyring, or a user keyring. Each key must be placed in a keyring that is "attached" to all processes that might need to access files encrypted with it, in the sense that request_key() will find the key. Generally, if only processes belonging to a specific user need to access a given encrypted directory and no session keyring has been installed, then that directory's key should be placed in that user's user session keyring or user keyring. Otherwise, a session keyring should be installed if needed, and the key should be linked into that session keyring, or in a keyring linked into that session keyring. Note: introducing the complex visibility semantics of keyrings here was arguably a mistake --- especially given that by design, after any process successfully opens an encrypted file (thereby setting up the per-file key), possessing the keyring key is not actually required for any process to read/write the file until its in-memory inode is evicted. In the future there probably should be a way to provide keys directly to the filesystem instead, which would make the intended semantics clearer. -- 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 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751852AbeAZAgz (ORCPT ); Thu, 25 Jan 2018 19:36:55 -0500 Received: from mail-io0-f182.google.com ([209.85.223.182]:40385 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751415AbeAZAgw (ORCPT ); Thu, 25 Jan 2018 19:36:52 -0500 X-Google-Smtp-Source: AH8x225gn3tFBIaF4BahvQOaDq0JsK/TyhafgDjcHLOV+2/OAujIzVE3t8dVWuPSKInJG609Ret4rg== Date: Thu, 25 Jan 2018 16:36:48 -0800 From: Eric Biggers To: =?iso-8859-1?Q?Andr=E9?= Draszik Cc: linux-kernel@vger.kernel.org, Mimi Zohar , David Howells , James Morris , "Serge E. Hallyn" , "Theodore Y. Ts'o" , Jaegeuk Kim , Kees Cook , Eric Biggers , linux-integrity@vger.kernel.org, keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fscrypt@vger.kernel.org Subject: Re: [PATCH v3] fscrypt: add support for the encrypted key type Message-ID: <20180126003648.jtmiznczkinla353@gmail.com> References: <20180118131359.8365-1-git@andred.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180118131359.8365-1-git@andred.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 18, 2018 at 01:13:59PM +0000, André Draszik wrote: > fscrypt uses a master key for each directory policy from > which all further keys for that policy are derived, and > at the moment such a master key has to be inserted into > a kernel keyring as a 'logon' key by user-space. > > While 'logon' keys have the nice property of not being > readable by user-space (keyctl dump etc.), the fscrypt There is no 'keyctl dump' command. Probably you meant 'keyctl read'. > master key still needs to be generated initially, in a > secure way, and it needs to be saved somewhere for > subsequent reboots, and hence also needs securing itself. > > Usage of the 'logon' key means that it is up to user-space > to do all that, opening up the possibility of creating > cryptographically non-sound master keys, or not storing > the master key securely across reboots. > > One approach for securing the master key would be to do > that using a TPM and while one could manually do so e.g. > using tpm-tools, that still leaves creation and actual > correct usage of tpm-tools up to user-space, though. As an > aside, tpm-tools needs the tcsd daemon running, which makes > it awkward to use from within an initramfs, and while other > libraries for interfacing with a TPM do exist, there > appears to be a better way: > > The kernel already has a concept of trusted as well as > encrypted keys. Trusted keys are TPM backed keys, which can > be sealed to PCRs and also easily be re-sealed against new > future PCRs, and encrypted keys are keys that are encrypted > using another key, e.g. a trusted key. All are generated > automatically by the kernel using the RNG and never leave > kernel memory space (bar any kernel or hardware bugs). Saying "the RNG" is unclear, since "encrypted" keys are generated using the kernel's RNG whereas "trusted" keys are generated using the TPM's RNG. > > So it seems reasonable to allow the fscrypt subsystem to > work with encrypted keys as well. This is what this change > here does. > > We can utilise keys that never ever exist in user-space, > not even at initial creation time, as well as simplifying > usage / configuration. Something very very similar exists > for eCrypts already. typo: eCrypts => eCryptfs [...] > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index 776ddc655f79..852ac2900b66 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -368,11 +368,19 @@ Adding keys > To provide a master key, userspace must add it to an appropriate > keyring using the add_key() system call (see: > ``Documentation/security/keys/core.rst``). The key type must be > -"logon"; keys of this type are kept in kernel memory and cannot be > -read back by userspace. The key description must be "fscrypt:" > -followed by the 16-character lower case hex representation of the > -``master_key_descriptor`` that was set in the encryption policy. The > -key payload must conform to the following structure:: > +either "logon" or "encrypted"; "logon" keys are kept in kernel > +memory and cannot be read back by userspace while "encrypted" > +keys can be rooted in a "trusted" key and thus are protected by > +a TPM and cannot be read by userspace in unencrypted form. Note > +that while an "encrypted" key can also be rooted in a "user" key, > +any "encrypted" key rooted in a "user" key can effectively be > +retrieved in the clear, hence only rooting the key in a "trusted" > +key has any useful security properties! > + > +The key description must be "fscrypt:" followed by the 16-character > +lower case hex representation of the ``master_key_descriptor`` that > +was set in the encryption policy. For a "logon" key, key payload > +must conform to the following structure:: > > #define FS_MAX_KEY_SIZE 64 > > @@ -386,6 +394,17 @@ key payload must conform to the following structure:: > ``raw`` with ``size`` indicating its size in bytes. That is, the > bytes ``raw[0..size-1]`` (inclusive) are the actual key. > > +When using an "encrypted" key, only the actual ``raw`` key from above > +fscrypt_key structure is needed:: > + > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-name`` ``size``" ``ring`` > + keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` > + > +Where:: > + > + master-key-name:= name of the trusted key this fscrypt master key > + shall be rooted in > + We need to be very careful with the wording. For example it's implied that encrypted keys cannot be read by userspace because they are protected by a TPM, but that's not true. They can be *wrapped* by a key which in turn can be TPM-sealed, but once unwrapped they are present in the clear in kernel memory, and it's only the policy of the kernel code that they can't be read back in the clear. Also the "logon" and "encrypted" key types should probably be in their own subsections, so that there is space to explain them properly. I've tried reorganizing the section a bit and this is what I came up with: Adding keys ----------- To provide a master key, userspace must add it to an appropriate keyring using the add_key() system call (see: ``Documentation/security/keys/core.rst``). The key description must be "fscrypt:" followed by the 16-character lower case hex representation of the ``master_key_descriptor`` that was set in the encryption policy. The "fscrypt:" prefix can alternatively be replaced with a filesystem-specific prefix such as "ext4:". However, the filesystem-specific prefixes are deprecated and should not be used in new programs. The key type must be "logon" or "encrypted", as described below. Support for the "logon" key type will always be available when any filesystem has fscrypt support enabled, whereas support for the "encrypted" key type additionally requires CONFIG_ENCRYPTED_KEYS=y. Logon key type ~~~~~~~~~~~~~~ With the "logon" type, userspace is responsible for generating or unwrapping the master key, then passing it to the kernel in the following format: #define FS_MAX_KEY_SIZE 64 struct fscrypt_key { u32 mode; u8 raw[FS_MAX_KEY_SIZE]; u32 size; }; ``mode`` is ignored; just set it to 0. The actual key is provided in ``raw`` with ``size`` indicating its size in bytes. That is, the bytes ``raw[0..size-1]`` (inclusive) are the actual key. The "logon" key will then be stored in kernel memory for the filesystem to use. There is no API for userspace to read it back. Encrypted key type ~~~~~~~~~~~~~~~~~~ With the "encrypted" key type, the key is initially randomly generated by the kernel. Then, userspace can read it back as a blob wrapped by another key. In particular, it can be wrapped by a "trusted" key, which can be sealed to a TPM in a certain state, with only the TPM-sealed blob being made available to userspace. Then, userspace can later re-instantiate the "encrypted" key by first re-instantiating the needed "trusted" key, then providing the encrypted-key blob to be unwrapped by the kernel. For example: # create a new encrypted-key keyctl add encrypted "fscrypt:``master_key_descriptor``" "new default trusted:``master-key-desc`` ``size``" ``ring`` # unwrap an existing encrypted-key blob keyctl add encrypted "fscrypt:``master_key_descriptor``" "load ``hex_blob``" ``ring`` Where:: master-key-desc:= description of the trusted key this fscrypt master key shall be wrapped by size := desired size of the fscrypt master key in bytes ring := keyring to add the key to The "encrypted" key must be instantiated using the "default" format, since its decrypted payload is treated as the raw master key; that is, the ``fscrypt_key`` structure is not used. Note that just like "logon" keys, "encrypted" keys are actually present in kernel memory in the clear after being added. Thus, they are not safe from attacks that compromise kernel memory. However, they cannot be read back in the clear using the system call interface. Choice of keyring ~~~~~~~~~~~~~~~~~ There are several different types of keyrings in which fscrypt master keys may be placed, such as a session keyring, a user session keyring, or a user keyring. Each key must be placed in a keyring that is "attached" to all processes that might need to access files encrypted with it, in the sense that request_key() will find the key. Generally, if only processes belonging to a specific user need to access a given encrypted directory and no session keyring has been installed, then that directory's key should be placed in that user's user session keyring or user keyring. Otherwise, a session keyring should be installed if needed, and the key should be linked into that session keyring, or in a keyring linked into that session keyring. Note: introducing the complex visibility semantics of keyrings here was arguably a mistake --- especially given that by design, after any process successfully opens an encrypted file (thereby setting up the per-file key), possessing the keyring key is not actually required for any process to read/write the file until its in-memory inode is evicted. In the future there probably should be a way to provide keys directly to the filesystem instead, which would make the intended semantics clearer.