Message ID | 20221115175652.3836811-2-roberto.sassu@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2865909wru; Tue, 15 Nov 2022 09:58:56 -0800 (PST) X-Google-Smtp-Source: AA0mqf5CuIOlIK4DmFQFRe5MHzpApGGb0FkGS+lscYFSe98hUN8zuSz4Vrzh5VK+6hFXd0j0Tj6R X-Received: by 2002:aa7:92c7:0:b0:56d:6450:9e48 with SMTP id k7-20020aa792c7000000b0056d64509e48mr19471653pfa.14.1668535135889; Tue, 15 Nov 2022 09:58:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668535135; cv=none; d=google.com; s=arc-20160816; b=G10tZpR4rPnLgOoU6wtWA2prWQQsq/XJX+ThGpDup5TSibY55quZvmre+OLMv/Xxxq jBr7KRhzDq/wkTPfZ1ywfPFivmhDdEj0wB9O7J4LKKCPPBwJbr8fnglULqBuL+ufEUI2 Sa+E4QbI2zJ0C6njpPnffTGMvRFXvhIPKkjKSZ/x/95pF378Rc7yXM3VVxyVLPXZdABV Ecs4z2zTWY7RnfVM5gbxFZA79oXweuISiB+1BBsHrlzeRaKZ/RyCFomf14fZQxAJJ4ZU Gni4Vakh0hFL9QvtfHXBycJrrZIFje1BgkFApREYk2w4HnyiUKivADehEDAbyRwCTGL8 HdmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=BusXxC44sdweHpFDad0INMRe3EIyodYT+A4/Adgegns=; b=jMlhCAz8h67AZ8rmvLHuLxhrGkA4mdAtozRJ8gEDux23ItAVVmP9tlR2rpM618dv9r ZJY+sIt9xQtNsAHF/zTBFGDwuecVPSOrdIlTyqSfrfacvsZR9pORtBpGgAGcM5gMkCHz ee7Gkg2uET3iF5p7bQWjv8V7kw3Zwin0263r4YnchEupH9ZcIq+XhhUkGEaYRL9qRLMy eA90B2WtamKAU/5+5lazCEljQEXzHcfCYWa6rZwigXkwMJyL7/G3rc3m97dM/plikFtE luupu9LrDe4wA0ESxFTj377tEC89pcYn1eIKGc9fehQxJlN/wy0D6HEUcQGd9fN8ar7Z EyCA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h190-20020a636cc7000000b0046ec05ccbe8si12256546pgc.380.2022.11.15.09.58.41; Tue, 15 Nov 2022 09:58:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231159AbiKOR5r (ORCPT <rfc822;maxim.cournoyer@gmail.com> + 99 others); Tue, 15 Nov 2022 12:57:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231415AbiKOR5m (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 15 Nov 2022 12:57:42 -0500 Received: from frasgout13.his.huawei.com (frasgout13.his.huawei.com [14.137.139.46]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E10CB2F3A6; Tue, 15 Nov 2022 09:57:39 -0800 (PST) Received: from mail02.huawei.com (unknown [172.18.147.229]) by frasgout13.his.huawei.com (SkyGuard) with ESMTP id 4NBYcv13TDz9xtmS; Wed, 16 Nov 2022 01:50:55 +0800 (CST) Received: from huaweicloud.com (unknown [10.204.63.22]) by APP1 (Coremail) with SMTP id LxC2BwCHcW7o0nNj73dpAA--.16599S3; Tue, 15 Nov 2022 18:57:16 +0100 (CET) From: Roberto Sassu <roberto.sassu@huaweicloud.com> To: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com, haoluo@google.com, jolsa@kernel.org, revest@chromium.org, jackmanb@chromium.org, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com Cc: bpf@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com> Subject: [RFC][PATCH 1/4] lsm: Clarify documentation of vm_enough_memory hook Date: Tue, 15 Nov 2022 18:56:49 +0100 Message-Id: <20221115175652.3836811-2-roberto.sassu@huaweicloud.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20221115175652.3836811-1-roberto.sassu@huaweicloud.com> References: <20221115175652.3836811-1-roberto.sassu@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: LxC2BwCHcW7o0nNj73dpAA--.16599S3 X-Coremail-Antispam: 1UD129KBjvdXoWruFy8GF18ZrWxtw17KrWUCFg_yoWkZrX_u3 4fG348Xw4fXF4xKa1IkF9aqryrK3yfXr1qgF1Yq39IqFWDAas5Gw4IgF9xX3Wqgwn293s5 uF97trWxAwnIgjkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbg8YFVCjjxCrM7AC8VAFwI0_Wr0E3s1l1xkIjI8I6I8E6xAIw20E Y4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l82xGYIkIc2x26280x7IE14v26r18M2 8IrcIa0xkI8VCY1x0267AKxVW8JVW5JwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK 021l84ACjcxK6xIIjxv20xvE14v26r1I6r4UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r 4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_ Gr1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ew Av7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY 6r1j6r4UM4x0Y48IcxkI7VAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxkF7I0En4kS14 v26r4a6rW5MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1I6r4UMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVW8Jr0_Cr1UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxV WUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4UJVWxJrUvcSsGvfC2KfnxnUUI43ZEXa7I U0GYLDUUUUU== X-CM-SenderInfo: purev21wro2thvvxqx5xdzvxpfor3voofrz/1tbiAgARBF1jj4F5bQAAsz X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749585898696680603?= X-GMAIL-MSGID: =?utf-8?q?1749585898696680603?= |
Series |
security: Ensure LSMs return expected values
|
|
Commit Message
Roberto Sassu
Nov. 15, 2022, 5:56 p.m. UTC
From: Roberto Sassu <roberto.sassu@huawei.com> include/linux/lsm_hooks.h reports the result of the LSM infrastructure to the callers, not what LSMs should return to the LSM infrastructure. Clarify that and add that returning 1 from the LSMs means calling __vm_enough_memory() with cap_sys_admin set, 0 without. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by: KP Singh <kpsingh@kernel.org> --- include/linux/lsm_hooks.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Comments
On Tue, Nov 15, 2022 at 12:57 PM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > include/linux/lsm_hooks.h reports the result of the LSM infrastructure to > the callers, not what LSMs should return to the LSM infrastructure. > > Clarify that and add that returning 1 from the LSMs means calling > __vm_enough_memory() with cap_sys_admin set, 0 without. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > Reviewed-by: KP Singh <kpsingh@kernel.org> > --- > include/linux/lsm_hooks.h | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > index 4ec80b96c22e..f40b82ca91e7 100644 > --- a/include/linux/lsm_hooks.h > +++ b/include/linux/lsm_hooks.h > @@ -1411,7 +1411,9 @@ > * Check permissions for allocating a new virtual mapping. > * @mm contains the mm struct it is being added to. > * @pages contains the number of pages. > - * Return 0 if permission is granted. > + * Return 0 if permission is granted by LSMs to the caller. LSMs should > + * return 1 if __vm_enough_memory() should be called with > + * cap_sys_admin set, 0 if not. I think this is a nice addition, but according to the code, any value greater than zero will trigger the caller-should-have-CAP_SYS_ADMIN behavior, not just 1. I suggest updating the comment.
On Tue, 2022-11-15 at 21:11 -0500, Paul Moore wrote: > On Tue, Nov 15, 2022 at 12:57 PM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > include/linux/lsm_hooks.h reports the result of the LSM infrastructure to > > the callers, not what LSMs should return to the LSM infrastructure. > > > > Clarify that and add that returning 1 from the LSMs means calling > > __vm_enough_memory() with cap_sys_admin set, 0 without. > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > Reviewed-by: KP Singh <kpsingh@kernel.org> > > --- > > include/linux/lsm_hooks.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > index 4ec80b96c22e..f40b82ca91e7 100644 > > --- a/include/linux/lsm_hooks.h > > +++ b/include/linux/lsm_hooks.h > > @@ -1411,7 +1411,9 @@ > > * Check permissions for allocating a new virtual mapping. > > * @mm contains the mm struct it is being added to. > > * @pages contains the number of pages. > > - * Return 0 if permission is granted. > > + * Return 0 if permission is granted by LSMs to the caller. LSMs should > > + * return 1 if __vm_enough_memory() should be called with > > + * cap_sys_admin set, 0 if not. > > I think this is a nice addition, but according to the code, any value > greater than zero will trigger the caller-should-have-CAP_SYS_ADMIN > behavior, not just 1. I suggest updating the comment. Ok, yes. Thanks. Roberto
On Wed, Nov 16, 2022 at 9:06 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > On Tue, 2022-11-15 at 21:11 -0500, Paul Moore wrote: > > On Tue, Nov 15, 2022 at 12:57 PM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > include/linux/lsm_hooks.h reports the result of the LSM infrastructure to > > > the callers, not what LSMs should return to the LSM infrastructure. > > > > > > Clarify that and add that returning 1 from the LSMs means calling > > > __vm_enough_memory() with cap_sys_admin set, 0 without. > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > Reviewed-by: KP Singh <kpsingh@kernel.org> > > > --- > > > include/linux/lsm_hooks.h | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > > index 4ec80b96c22e..f40b82ca91e7 100644 > > > --- a/include/linux/lsm_hooks.h > > > +++ b/include/linux/lsm_hooks.h > > > @@ -1411,7 +1411,9 @@ > > > * Check permissions for allocating a new virtual mapping. > > > * @mm contains the mm struct it is being added to. > > > * @pages contains the number of pages. > > > - * Return 0 if permission is granted. > > > + * Return 0 if permission is granted by LSMs to the caller. LSMs should > > > + * return 1 if __vm_enough_memory() should be called with > > > + * cap_sys_admin set, 0 if not. > > > > I think this is a nice addition, but according to the code, any value > > greater than zero will trigger the caller-should-have-CAP_SYS_ADMIN > > behavior, not just 1. I suggest updating the comment. > > Ok, yes. Thanks. Also, this is an unrelated patch and you can probably send it independently, especially since the other changes will now land mostly via BPF. > > Roberto >
On Wed, Nov 16, 2022 at 2:18 PM KP Singh <kpsingh@kernel.org> wrote: > On Wed, Nov 16, 2022 at 9:06 AM Roberto Sassu > <roberto.sassu@huaweicloud.com> wrote: > > > > On Tue, 2022-11-15 at 21:11 -0500, Paul Moore wrote: > > > On Tue, Nov 15, 2022 at 12:57 PM Roberto Sassu > > > <roberto.sassu@huaweicloud.com> wrote: > > > > From: Roberto Sassu <roberto.sassu@huawei.com> > > > > > > > > include/linux/lsm_hooks.h reports the result of the LSM infrastructure to > > > > the callers, not what LSMs should return to the LSM infrastructure. > > > > > > > > Clarify that and add that returning 1 from the LSMs means calling > > > > __vm_enough_memory() with cap_sys_admin set, 0 without. > > > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > > > Reviewed-by: KP Singh <kpsingh@kernel.org> > > > > --- > > > > include/linux/lsm_hooks.h | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h > > > > index 4ec80b96c22e..f40b82ca91e7 100644 > > > > --- a/include/linux/lsm_hooks.h > > > > +++ b/include/linux/lsm_hooks.h > > > > @@ -1411,7 +1411,9 @@ > > > > * Check permissions for allocating a new virtual mapping. > > > > * @mm contains the mm struct it is being added to. > > > > * @pages contains the number of pages. > > > > - * Return 0 if permission is granted. > > > > + * Return 0 if permission is granted by LSMs to the caller. LSMs should > > > > + * return 1 if __vm_enough_memory() should be called with > > > > + * cap_sys_admin set, 0 if not. > > > > > > I think this is a nice addition, but according to the code, any value > > > greater than zero will trigger the caller-should-have-CAP_SYS_ADMIN > > > behavior, not just 1. I suggest updating the comment. > > > > Ok, yes. Thanks. > > Also, this is an unrelated patch and you can probably send it > independently, especially > since the other changes will now land mostly via BPF. Yes, the doc/comment changes really have nothing to do with the other stuff we are discussing in this patchset.
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 4ec80b96c22e..f40b82ca91e7 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -1411,7 +1411,9 @@ * Check permissions for allocating a new virtual mapping. * @mm contains the mm struct it is being added to. * @pages contains the number of pages. - * Return 0 if permission is granted. + * Return 0 if permission is granted by LSMs to the caller. LSMs should + * return 1 if __vm_enough_memory() should be called with + * cap_sys_admin set, 0 if not. * * @ismaclabel: * Check if the extended attribute specified by @name