From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lakshmi Ramasubramanian Date: Tue, 03 Dec 2019 16:09:20 +0000 Subject: Re: [PATCH v0 2/2] IMA: Call queue functions to measure keys Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="maccentraleurope" Content-Transfer-Encoding: base64 List-Id: References: <20191127025212.3077-1-nramas@linux.microsoft.com> <20191127025212.3077-3-nramas@linux.microsoft.com> <1575331353.4793.471.camel@linux.ibm.com> In-Reply-To: <1575331353.4793.471.camel@linux.ibm.com> To: Mimi Zohar , linux-integrity@vger.kernel.org Cc: eric.snowberg@oracle.com, dhowells@redhat.com, matthewgarrett@google.com, sashal@kernel.org, jamorris@linux.microsoft.com, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org VGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGNoYW5nZXMgTWltaS4gSSdsbCBhZGRyZXNzIHlvdXIg Y29tbWVudHMgaW4gdGhlIApuZXh0IHVwZGF0ZS4KCj4gCj4gT3ZlcndyaXRpbmcgdGhlIGluaXRp YWwgcG9saWN5IGlzIGhpZ2hseSByZWNvbW1lbmRlZCwgYnV0IG5vdCBldmVyeW9uZQo+IGRlZmlu ZXMgYSBjdXN0b20gcG9saWN5LiDCoFNob3VsZCB0aGVyZSBiZSBhIHRpbWUgbGltaXQgb3Igc29t ZSBvdGhlcgo+IGNyaXRlcmlhIGJlZm9yZSBkZWxldGluZyB0aGUga2V5IG1lYXN1cmVtZW50IHF1 ZXVlPwo+IAo+IE1pbWkKCkZvciB0aGUgYWJvdmUsIEkgZmVlbCBjaGVja2luZyBmb3IgdGhlIHBy ZXNlbmNlIG9mIGN1c3RvbSBwb2xpY3ksIGlmIAp0aGF0IGlzIHBvc3NpYmxlLCB3b3VsZCBiZSBh IG1vcmUgZGV0ZXJtaW5pc3RpYyBhcHByb2FjaCBjb21wYXJlZCB0byAKaGF2aW5nIGEgdGltZSBs aW1pdC4KCk9uIG15IG1hY2hpbmUsIHN5c3RlbWQgbG9hZHMgdGhlIGN1c3RvbSBJTUEgcG9saWN5 IGZyb20gCi9ldGMvaW1hL2ltYS1wb2xpY3kgaWYgdGhhdCBmaWxlIGlzIHByZXNlbnQuIElzIHRo aXMgdGhlIHJlY29tbWVuZGVkIHdheSAKdG8gY29uZmlndXJlIGN1c3RvbSBJTUEgcG9saWN5PyBJ ZiB5ZXMsIGNhbiB0aGUgSU1BIGluaXRpYWxpemF0aW9uIApmdW5jdGlvbiBjaGVjayBmb3IgdGhl IHByZXNlbmNlIG9mIHRoZSBhYm92ZSBmaWxlPwoKQW5vdGhlciB3YXkgdG8gYWRkcmVzcyB0aGlz IGlzc3VlIGlzIHRvIGRlZmluZSBhIG5ldyBDT05GSUcgcGFyYW1ldGVyIHRvIApkZXRlcm1pbmUg d2hldGhlciBvciBub3QgdG8gc3VwcG9ydCBkZWZlcnJlZCBwcm9jZXNzaW5nIG9mIGtleXMuIElm IHRoaXMgCmNvbmZpZyBpcyBjaG9zZW4sIGN1c3RvbSBJTUEgcG9saWN5IG11c3QgYmUgZGVmaW5l ZC4KCkxlYXN0IHByZWZlcnJlZCBvcHRpb24gd291bGQgYmUgdG8gbGVhdmUgdGhlIHF1ZXVlZCBr ZXlzIGFzIGlzIGlmIGN1c3RvbSAKcG9saWN5IGlzIG5vdCBkZWZpbmVkIC0gYXQgdGhlIGNvc3Qg b2YsIG1heWJlLCBhIG5vbi10cml2aWFsIGFtb3VudCBvZiAKa2VybmVsIG1lbW9yeSBjb25zdW1l ZC4KCklmIGRldGVjdGlvbiBvZiBjdXN0b20gcG9saWN5IGlzIG5vdCBwb3NzaWJsZSwgdGhlbiBk ZWZpbmUgYSB0aW1lciB0byAKZHJhaW4gdGhlIGtleSBtZWFzdXJlbWVudCBxdWV1ZS4KClBsZWFz ZSBsZXQgbWUga25vdyB3aGljaCBhcHByb2FjaCB5b3UgdGhpbmsgaXMgb3B0aW1hbC4KCnRoYW5r cywKICAtbGFrc2htaQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 221C7C432C0 for ; Tue, 3 Dec 2019 16:09:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EA1A620833 for ; Tue, 3 Dec 2019 16:09:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="j0N/i9Wx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727118AbfLCQJD (ORCPT ); Tue, 3 Dec 2019 11:09:03 -0500 Received: from linux.microsoft.com ([13.77.154.182]:54174 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727113AbfLCQJC (ORCPT ); Tue, 3 Dec 2019 11:09:02 -0500 Received: from [10.137.112.111] (unknown [131.107.147.111]) by linux.microsoft.com (Postfix) with ESMTPSA id AFB6B20B7185; Tue, 3 Dec 2019 08:09:01 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com AFB6B20B7185 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1575389341; bh=cA2NvMvX1jL063jiAdOXXSP1Gwaopiy2VeenLg73h9E=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=j0N/i9Wx4wwKdNtHrm2WiqBSSaRnzd0P4Nju3IvAxxS1CcFNHA3MS/3Q3Os/4QHLJ 2VDp4boCAXWBWDXj/bLxU3qp2OP7YXQDEMkLUN4VO6HVwQAK0bZLSdCq2QjyWVbTG9 gjmLXK0hvdRzNV5jLvVrMYJiEbObjEC6RYJyjR5o= Subject: Re: [PATCH v0 2/2] IMA: Call queue functions to measure keys To: Mimi Zohar , linux-integrity@vger.kernel.org Cc: eric.snowberg@oracle.com, dhowells@redhat.com, matthewgarrett@google.com, sashal@kernel.org, jamorris@linux.microsoft.com, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org References: <20191127025212.3077-1-nramas@linux.microsoft.com> <20191127025212.3077-3-nramas@linux.microsoft.com> <1575331353.4793.471.camel@linux.ibm.com> From: Lakshmi Ramasubramanian Message-ID: Date: Tue, 3 Dec 2019 08:09:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <1575331353.4793.471.camel@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org Thanks for reviewing the changes Mimi. I'll address your comments in the next update. > > Overwriting the initial policy is highly recommended, but not everyone > defines a custom policy.  Should there be a time limit or some other > criteria before deleting the key measurement queue? > > Mimi For the above, I feel checking for the presence of custom policy, if that is possible, would be a more deterministic approach compared to having a time limit. On my machine, systemd loads the custom IMA policy from /etc/ima/ima-policy if that file is present. Is this the recommended way to configure custom IMA policy? If yes, can the IMA initialization function check for the presence of the above file? Another way to address this issue is to define a new CONFIG parameter to determine whether or not to support deferred processing of keys. If this config is chosen, custom IMA policy must be defined. Least preferred option would be to leave the queued keys as is if custom policy is not defined - at the cost of, maybe, a non-trivial amount of kernel memory consumed. If detection of custom policy is not possible, then define a timer to drain the key measurement queue. Please let me know which approach you think is optimal. thanks, -lakshmi