Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp2384919rdb; Tue, 10 Oct 2023 02:14:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFGWBcnPV6fKl/RrjDUD6KXO4ivvBh9INZjJTvl4yEEMIM7YRF/uHheVJR0/vXESlI2DItw X-Received: by 2002:a17:902:be03:b0:1c4:c5d:d7fa with SMTP id r3-20020a170902be0300b001c40c5dd7famr13685928pls.45.1696929267023; Tue, 10 Oct 2023 02:14:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696929267; cv=none; d=google.com; s=arc-20160816; b=qp2hrcTHmkiEBjfzBNERiZQ8GKtmbcLF5dmnPz8IAnwHoLaEYb1FOcGhWfba50Y4t/ 2jvnW0mG5JZjx4lCgK4NFTXXb1vJGeSUkvDqWqvy6bf50XIWUBGBWpq+RopWnMysnvCI v26h4/KlIf9G7rbFf3mDqXbmHE2TpxXprGhaMGshd2aQEtQnFE7La6yDwFJ+/BeQscxv b+VjqbNAtevqCqFiG2o21qRMuO+wZvOzNu5ntYVlp+X7Avcxp9GCkKv6KpgTmAl+z4S/ jTkgI7cTsXlcH62oCaLKylK/7xgtNWOibnOEih3Z1AH5byGHaNTxacORGOLRznlF8NoJ WUsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=oJvDRm2DlL3luNMLGN0ZrSLUEjUog1y2Ev8apRG1Vg4=; fh=AsfdvPVT3rSUN9hhA9fbuPUyScBRzHCpdiSfGu8xUBI=; b=c0aGuejFQdXcA7QEEu1jsZv8jzt7/Wf4XXLdmq/6MjUbTnaXYi6DSJ0mggBgLmBnzg K01HaVqnncTaC/GdwVPge+2bs1Emaegzv+DL6wYO4h1Xbs0Tdckr+IfxtXOCseEB7Yv1 f5frnlUWuvwFggMkpNPuvxWv2QZyMu7F0woHJgL+Z2BsaiOkpoSdb/eeNyD79BFJEGV0 hg4O8YC4l0fslhYUC5FeS7rsHdAwS7tOos8WVgeRMwMkpa8G79fNeAp7YLzSn3qCrfzi RUoRF/2hhs6vSWt2FgXpSDFpT1A8cgoIWPFLT4l0NdDzDWtwRNZZRyf+yUV2jcBl/GjX nXxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b="U7+/Im0Q"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from pete.vger.email (pete.vger.email. [23.128.96.36]) by mx.google.com with ESMTPS id k4-20020a170902d58400b001bde0b58abesi11523722plh.161.2023.10.10.02.14.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 02:14:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36; Authentication-Results: mx.google.com; dkim=pass header.i=@digikod.net header.s=20191114 header.b="U7+/Im0Q"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 8A4D68023771; Tue, 10 Oct 2023 02:14:23 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229679AbjJJJOK (ORCPT + 99 others); Tue, 10 Oct 2023 05:14:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229516AbjJJJOJ (ORCPT ); Tue, 10 Oct 2023 05:14:09 -0400 Received: from smtp-190e.mail.infomaniak.ch (smtp-190e.mail.infomaniak.ch [IPv6:2001:1600:4:17::190e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C473D93 for ; Tue, 10 Oct 2023 02:14:06 -0700 (PDT) Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4S4VZj0J0qzMq9pR; Tue, 10 Oct 2023 09:14:05 +0000 (UTC) Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4S4VZd3TbZzMppBm; Tue, 10 Oct 2023 11:14:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1696929244; bh=DmhMn+vZSARxLDuUBIWnbvYSOLeU0DysGOMTDQ6nU4Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U7+/Im0QDANsJTlneaGyYRsleuvfIKUJmYhchY5Y9icq0OgAbXBPe3xltkdhfE0pn U3Fg7ERD+Ps6OEmTupWdekJ6jJCYn5ZfC3MHL6CQqLx0w/ivytjPTzPLsSmwlqZCCl lOatDcGlutBWmFfJAHlScHxSf0ZpD0BwskkcPYxQ= Date: Tue, 10 Oct 2023 11:14:00 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Paul Moore Cc: Casey Schaufler , linux-security-module@vger.kernel.org, jmorris@namei.org, serge@hallyn.com, keescook@chromium.org, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH v15 04/11] LSM: syscalls for current process attributes Message-ID: <20231010.eisha1Fohj8u@digikod.net> References: <20230912205658.3432-1-casey@schaufler-ca.com> <20230912205658.3432-5-casey@schaufler-ca.com> <20231003.kooghohS2Aiz@digikod.net> <20231009.MieQu5ou2loo@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Infomaniak-Routing: alpha X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 10 Oct 2023 02:14:23 -0700 (PDT) X-Spam-Level: ** On Mon, Oct 09, 2023 at 12:04:31PM -0400, Paul Moore wrote: > On Mon, Oct 9, 2023 at 11:37 AM Mickaël Salaün wrote: > > On Thu, Oct 05, 2023 at 09:04:34PM -0400, Paul Moore wrote: > > > On Tue, Oct 3, 2023 at 10:09 AM Mickaël Salaün wrote: > > > > On Tue, Sep 12, 2023 at 01:56:49PM -0700, Casey Schaufler wrote: > > > > > Create a system call lsm_get_self_attr() to provide the security > > > > > module maintained attributes of the current process. > > > > > Create a system call lsm_set_self_attr() to set a security > > > > > module maintained attribute of the current process. > > > > > Historically these attributes have been exposed to user space via > > > > > entries in procfs under /proc/self/attr. > > > > > > > > > > The attribute value is provided in a lsm_ctx structure. The structure > > > > > identifies the size of the attribute, and the attribute value. The format > > > > > of the attribute value is defined by the security module. A flags field > > > > > is included for LSM specific information. It is currently unused and must > > > > > be 0. The total size of the data, including the lsm_ctx structure and any > > > > > padding, is maintained as well. > > > > > > > > > > struct lsm_ctx { > > > > > __u64 id; > > > > > __u64 flags; > > > > > __u64 len; > > > > > __u64 ctx_len; > > > > > __u8 ctx[]; > > > > > }; > > > > > > > > > > Two new LSM hooks are used to interface with the LSMs. > > > > > security_getselfattr() collects the lsm_ctx values from the > > > > > LSMs that support the hook, accounting for space requirements. > > > > > security_setselfattr() identifies which LSM the attribute is > > > > > intended for and passes it along. > > > > > > > > > > Signed-off-by: Casey Schaufler > > > > > Reviewed-by: Kees Cook > > > > > Reviewed-by: Serge Hallyn > > > > > Reviewed-by: John Johansen > > > > > --- > > > > > Documentation/userspace-api/lsm.rst | 70 +++++++++++++ > > > > > include/linux/lsm_hook_defs.h | 4 + > > > > > include/linux/lsm_hooks.h | 1 + > > > > > include/linux/security.h | 19 ++++ > > > > > include/linux/syscalls.h | 5 + > > > > > include/uapi/linux/lsm.h | 36 +++++++ > > > > > kernel/sys_ni.c | 2 + > > > > > security/Makefile | 1 + > > > > > security/lsm_syscalls.c | 57 +++++++++++ > > > > > security/security.c | 152 ++++++++++++++++++++++++++++ > > > > > 10 files changed, 347 insertions(+) > > > > > create mode 100644 Documentation/userspace-api/lsm.rst > > > > > create mode 100644 security/lsm_syscalls.c > > > > > > ... > > > > > > > > diff --git a/security/security.c b/security/security.c > > > > > index a3489c04b783..0d179750d964 100644 > > > > > --- a/security/security.c > > > > > +++ b/security/security.c > > > > > @@ -3837,6 +3837,158 @@ void security_d_instantiate(struct dentry *dentry, struct inode *inode) > > > > > } > > > > > EXPORT_SYMBOL(security_d_instantiate); > > > > > > > > > > +/* > > > > > + * Please keep this in sync with it's counterpart in security/lsm_syscalls.c > > > > > + */ > > > > > + > > > > > +/** > > > > > + * security_getselfattr - Read an LSM attribute of the current process. > > > > > + * @attr: which attribute to return > > > > > + * @uctx: the user-space destination for the information, or NULL > > > > > + * @size: pointer to the size of space available to receive the data > > > > > + * @flags: special handling options. LSM_FLAG_SINGLE indicates that only > > > > > + * attributes associated with the LSM identified in the passed @ctx be > > > > > + * reported. > > > > > + * > > > > > + * A NULL value for @uctx can be used to get both the number of attributes > > > > > + * and the size of the data. > > > > > + * > > > > > + * Returns the number of attributes found on success, negative value > > > > > + * on error. @size is reset to the total size of the data. > > > > > + * If @size is insufficient to contain the data -E2BIG is returned. > > > > > + */ > > > > > +int security_getselfattr(unsigned int attr, struct lsm_ctx __user *uctx, > > > > > + size_t __user *size, u32 flags) > > > > > +{ > > > > > + struct security_hook_list *hp; > > > > > + struct lsm_ctx lctx = { .id = LSM_ID_UNDEF, }; > > > > > + u8 __user *base = (u8 __user *)uctx; > > > > > + size_t total = 0; > > > > > + size_t entrysize; > > > > > + size_t left; > > > > > + bool toobig = false; > > > > > + bool single = false; > > > > > + int count = 0; > > > > > + int rc; > > > > > + > > > > > + if (attr == LSM_ATTR_UNDEF) > > > > > + return -EINVAL; > > > > > + if (size == NULL) > > > > > + return -EINVAL; > > > > > + if (get_user(left, size)) > > > > > + return -EFAULT; > > > > > + > > > > > + if (flags) { > > > > > + /* > > > > > + * Only flag supported is LSM_FLAG_SINGLE > > > > > + */ > > > > > + if (flags != LSM_FLAG_SINGLE) > > > > > + return -EINVAL; > > > > > + if (uctx && copy_from_user(&lctx, uctx, sizeof(lctx))) > > > > > > > > I'm not sure if we should return -EINVAL or -EFAULT when uctx == NULL. > > > > Because uctx is optional (when LSM_FLAG_SINGLE is not set), I guess > > > > -EINVAL is OK. > > > > > > That's a good point, we should probably the error codes here: if uctx > > > is NULL in the LSM_FLAG_SINGLE case we should return -EINVAL, if the > > > copy_from_user() fails we should return -EFAULT. > > > > > > > > + return -EFAULT; > > > > > + /* > > > > > + * If the LSM ID isn't specified it is an error. > > > > > + */ > > > > > + if (lctx.id == LSM_ID_UNDEF) > > > > > + return -EINVAL; > > > > > + single = true; > > > > > + } > > > > > + > > > > > + /* > > > > > + * In the usual case gather all the data from the LSMs. > > > > > + * In the single case only get the data from the LSM specified. > > > > > + */ > > > > > + hlist_for_each_entry(hp, &security_hook_heads.getselfattr, list) { > > > > > + if (single && lctx.id != hp->lsmid->id) > > > > > + continue; > > > > > + entrysize = left; > > > > > + if (base) > > > > > + uctx = (struct lsm_ctx __user *)(base + total); > > > > > + rc = hp->hook.getselfattr(attr, uctx, &entrysize, flags); > > > > > + if (rc == -EOPNOTSUPP) { > > > > > + rc = 0; > > > > > + continue; > > > > > + } > > > > > + if (rc == -E2BIG) { > > > > > + toobig = true; > > > > > + left = 0; > > > > > + } else if (rc < 0) > > > > > + return rc; > > > > > + else > > > > > + left -= entrysize; > > > > > + > > > > > + total += entrysize; > > > > > + count += rc; > > > > > > > > There is a bug if rc == -E2BIG > > > > > > Can you elaborate a bit more on this? Nothing is jumping out at me as > > > obviously broken... are you talking about @count becoming garbage due > > > to @rc being equal to -E2BIG? If that is the case it should be okay > > > since we explicitly return -E2BIG, not @count, if @toobig is true. > > > > Indeed, in this case count will not be returned thanks to toobig. I'd > > suggest to "continue" if rc == -E2BIG (like for -EOPNOTSUPP) to avoid an > > inconsistent count value, which could bite us one day. > > Okay, how about we reset @rc to zero in the -E2BIG case? We don't > want to bypass the lower part of the loop in this case as we still > need to update @total. > > if (rc == -E2BIG) { > rc = 0; > left = 0; > toobig = true; > } Indeed, this is better. To avoid useless calls to getselfattr hooks, we could also patch the last part of the loop: - if (single) + if (single || left <= 0) break; > > -- > paul-moore.com