Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1955334ybl; Tue, 3 Dec 2019 15:37:44 -0800 (PST) X-Google-Smtp-Source: APXvYqzWWStjGT2uDy4y67lzNFSRN9oXWy0m1MYj2W48NjfbBkZo+7kM+hfi9TWWXyK9bTfEiEXX X-Received: by 2002:aca:52c7:: with SMTP id g190mr214181oib.84.1575416264547; Tue, 03 Dec 2019 15:37:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575416264; cv=none; d=google.com; s=arc-20160816; b=AQEbHAhrJOgOd/LtUbwuOf0Vf/x2fI817aBt3JaGrNeUPSrJOB7vtcaOKcFHthsyKk tmWzJGlBBqT5sDl7VcSMlQe6b5LCAY3q6lUcBM+aw8gFpvYpw85uZtf7/KOfOhXIuFhU ylZYWArM59lrBms1iHh5qnhMXchRV1QURt+fz7rNFmxLXE85shickLiXfWGlnbxM2gQV cDbGFbhZpZcBDLzgZQMap8Ty6o3qJlsLAWZkV9OTcmc4vAC3cr1Q8ZhYwLucGFlZFhRQ AyeDYUm8MgS0/cI2XmZokoNg+/2txoXtlsfD/eOJTOrNRN3tbg47w0U2yMKeBX3On6Kd eDzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature:dkim-filter; bh=lumjR+WsAH17zIElti4at56HiP3oZKr0jeW3mqpgrHY=; b=r2u+z0bOnlQPjve3WHl4cYrEBl9tbybLHPq0SpmOQAZ29y6o24hniEMs7c6RBe2ax4 nTv320ZpXEttTvjyvNAoRny7Tr5i1QVmWELaNtyDx0d58T8Z74WfUSO1jPVtNqhbT8fd Z4y0HeAroiF8KhRzOBlagY9pMZVRO0wJmLgA0GcDIqwjNK/I/W1d38u3o6/HHAHg3aE7 6KUtOkFP/7OwSZ5BPBZeYzQnoMdEekSbMokD89ttcUgm8ctQTPJLZrPOPd67Y8ZNQpkw BspqeQiDhJkflEmR6JG2K1UpJ2SMND31RIP4Dfe2nIG7TNwDKwHhU5o65V0fFvgrO/fs MY6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=de947gFn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z7si2407473otj.137.2019.12.03.15.37.29; Tue, 03 Dec 2019 15:37:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=de947gFn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726707AbfLCXg7 (ORCPT + 99 others); Tue, 3 Dec 2019 18:36:59 -0500 Received: from linux.microsoft.com ([13.77.154.182]:43348 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726144AbfLCXg7 (ORCPT ); Tue, 3 Dec 2019 18:36:59 -0500 Received: from [10.137.112.111] (unknown [131.107.147.111]) by linux.microsoft.com (Postfix) with ESMTPSA id 8BAC120B7185; Tue, 3 Dec 2019 15:36:58 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 8BAC120B7185 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1575416218; bh=lumjR+WsAH17zIElti4at56HiP3oZKr0jeW3mqpgrHY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=de947gFnmNyOixr7N1TMZYsinoGV2xsUKN/WwfHNuRjXgU61OunOF3SifgKSmF89G bRi33LhmfBFfM/IFU2Yu66gQvpR3cgchy6aY4zm9ohJ6QAoEEtnJ4fz2nu5HSPCeTw tz7djkOq501rwSmZC9Tc6rKg2AJjuDbXf14n6PTs= Subject: Re: [PATCH v9 5/6] IMA: Add support to limit measuring 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: <20191127015654.3744-1-nramas@linux.microsoft.com> <20191127015654.3744-6-nramas@linux.microsoft.com> <1575375945.5241.16.camel@linux.ibm.com> <2d20ce36-e24e-e238-4a82-286db9eeab97@linux.microsoft.com> <1575403616.5241.76.camel@linux.ibm.com> From: Lakshmi Ramasubramanian Message-ID: <89bb3226-3a2e-c7fa-fff9-3a422739481c@linux.microsoft.com> Date: Tue, 3 Dec 2019 15:37:17 -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: <1575403616.5241.76.camel@linux.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/3/2019 12:06 PM, Mimi Zohar wrote: > Suppose both root and uid 1000 define a keyring named "foo".  The > current "keyrings=foo" will measure all keys added to either keyring > named "foo".  There needs to be a way to limit measuring keys to a > particular keyring named "foo". > > Mimi Thanks for clarifying. Suppose two different non-root users create keyring with the same name "foo" and, say, both are measured, how would we know which keyring measurement belongs to which user? Wouldn't it be sufficient to include only keyrings created by "root" (UID value 0) in the key measurement? This will include all the builtin trusted keyrings (such as .builtin_trusted_keys, .secondary_trusted_keys, .ima, .evm, etc.). What would be the use case for including keyrings created by non-root users in key measurement? Also, since the UID for non-root users can be any integer value (greater than 0), can an an administrator craft a generic IMA policy that would be applicable to all clients in an enterprise? thanks, -lakshmi