Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5042670pxb; Wed, 26 Jan 2022 03:38:42 -0800 (PST) X-Google-Smtp-Source: ABdhPJwC/jN2hFW/QiG+bI7StdX7WnUxgm2pX9nY7MjnpKkGOJjpIGUz5cjrqy3J2JInORzstU3H X-Received: by 2002:a17:906:7e10:: with SMTP id e16mr20212581ejr.143.1643197122599; Wed, 26 Jan 2022 03:38:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643197122; cv=none; d=google.com; s=arc-20160816; b=Wou2tvBjk6lJaXQeNvYSApPrFuFsAzPFfRJ6gZU10r5dVXJ8yxe2osD8ChznNR9Gt7 t1O50WpRSx155Je+k0nTy0dzB4Uyz7AIMYpzFBy/Mh7nZU1TcTkKCWt6ExYHswRla+Bp vBoirH1Hd2ToysAbww9dW0w3c7Fzv3bycZZj2WB8i9pCh1RVvd1eeXpqrS4M2fl6Reog Fd9NKjm9GT6pQQCc+YlM8QsVq39xgxv6Wxjx1tpsS5MWqfz/xSabU3YU2qIfITSApyKw wf1+FUVRlEpBKmdH046C2Wi31faQSrHYN9OuvBrC/tE4/yCn2nFUjBRNNmuQkO7NcQC/ BlFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=oeeJHO8TMWJMimBDwT2b+COdmax7x8vmymErPKX3jxc=; b=ZvDCUu6JEXRRLiEEu12OS+L6MPkaWd/YD5FnLF9QOFzLN0gqYVYvSC5PV0eEodbYcm nxe/O48Qge/a/lMx6InhefNmRkv6z27/89nk5oHuPpOTnssFSvMFpd+Hgx6Vv5kHpUI3 Z0Wre54elWhKq9YSfWVTGys/1P9F0+cE8atS1nkn8n1Zfo2hc76KkU2sxHEZA9BBLqiG YR/5ecKpiX1ptW/1Psn41Qxb2K89lYq+owplRB53hZBykDbJeeuJ7zuOexr5HhdZ2hYB B6qXFFLJDlmxJlI6vU09uAvCuiZoJMHBjFNRjYSpO0G8Cm3JPiYvrcNTyxHpzj5FaLRO bG5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=DzijtXi0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gs13si12762679ejc.524.2022.01.26.03.38.16; Wed, 26 Jan 2022 03:38:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20210112.gappssmtp.com header.s=20210112 header.b=DzijtXi0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233887AbiAYWdI (ORCPT + 99 others); Tue, 25 Jan 2022 17:33:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233879AbiAYWdH (ORCPT ); Tue, 25 Jan 2022 17:33:07 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B165EC061747 for ; Tue, 25 Jan 2022 14:33:06 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id j2so33764941ejk.6 for ; Tue, 25 Jan 2022 14:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oeeJHO8TMWJMimBDwT2b+COdmax7x8vmymErPKX3jxc=; b=DzijtXi0FpfwwMBwStqu3UmmHy6WLI6KJjaJCTw5TVkmEqNdXft9MrLSeXBntoO7Mw fWSvmO7h/R5mQ/yU+34k8tfHIU5T7UxRE0tWGCE66lLTfaILezBkt/1UkJvP9pVH0Yzb HHNrjbdaOKT86FyOQ4Jf88N4t5t/R3zJhuJwDslag8fbYnvwj1+kSYMm+Az5xDFrSoYc knCjS+ili0zFQfE5Tfu8zpiesGviybOMiD+yOzaswnbUAmmPC8T35oz+wE4i8da9xo9A Cxn3uNaT3ALpZ+5PyJS8v8W9GaSLLCJqkiGKhzgIDTWBp7Qme5nzQ2I/BzjbPf8Vhkt1 p03Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oeeJHO8TMWJMimBDwT2b+COdmax7x8vmymErPKX3jxc=; b=JdnRgCloOEWoS08EcKaXSDozVKLPNc5v1VEG4MpSf6WtsLJt9FYtonxfuZ0ySfhZfT K2OaFRck4Q3YHsSb8GEbPPrZ0aNEBmJr5TRpdygFXNuHinc9o8hQjVp5PAU7qRZYVlsK 70Uapa0nHcpzXtY3sAyPiz5gHg8Jhw6s9MPq/v4sns260OhsO/p5tQq33XvjPDavE62A +sszdYVbrXCkX6uy3lEUP5X/lz5tNTras3hUDInzxjLeC8u5FOQFio8/Pf5Nt/WstVWg K+zkbQCGmAYv2Wli1lqoSVzSqJOjtwab+QRyerDyYzMNjR6hy0b315LfY0wCeo9L9ZY6 wfAQ== X-Gm-Message-State: AOAM533tgzlalutESzkH0Ex888k69/W+8AKOSSeNlZNTxBCY1cQoCI/L bx43ETlwY0EjYre8kVDKSnFscYVSTGD4ClFoCV9w X-Received: by 2002:a17:907:6d03:: with SMTP id sa3mr4722991ejc.517.1643149985174; Tue, 25 Jan 2022 14:33:05 -0800 (PST) MIME-Version: 1.0 References: <20220120214948.3637895-1-smayhew@redhat.com> <20220120214948.3637895-2-smayhew@redhat.com> In-Reply-To: From: Paul Moore Date: Tue, 25 Jan 2022 17:32:54 -0500 Message-ID: Subject: Re: [PATCH RFC v2 1/2] selinux: Fix selinux_sb_mnt_opts_compat() To: Scott Mayhew Cc: selinux@vger.kernel.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 25, 2022 at 1:51 PM Scott Mayhew wrote: > On Tue, 25 Jan 2022, Paul Moore wrote: > > On Tue, Jan 25, 2022 at 12:31 PM Scott Mayhew wrote: > > > On Mon, 24 Jan 2022, Paul Moore wrote: > > > > On Thu, Jan 20, 2022 at 4:50 PM Scott Mayhew wrote: > > > > > > > > > > selinux_sb_mnt_opts_compat() is called under the sb_lock spinlock and > > > > > shouldn't be performing any memory allocations. Fix this by parsing the > > > > > sids at the same time we're chopping up the security mount options > > > > > string and then using the pre-parsed sids when doing the comparison. > > > > > > > > > > Fixes: cc274ae7763d ("selinux: fix sleeping function called from invalid context") > > > > > Fixes: 69c4a42d72eb ("lsm,selinux: add new hook to compare new mount to an existing mount") > > > > > Signed-off-by: Scott Mayhew > > > > > --- > > > > > security/selinux/hooks.c | 112 ++++++++++++++++++++++++++------------- > > > > > 1 file changed, 76 insertions(+), 36 deletions(-) > > > > ... > > > > > > > switch (token) { > > > > > case Opt_context: > > > > > if (opts->context || opts->defcontext) > > > > > goto err; > > > > > opts->context = s; > > > > > + if (preparse_sid) { > > > > > + rc = parse_sid(NULL, s, &sid); > > > > > + if (rc == 0) { > > > > > + opts->context_sid = sid; > > > > > + opts->preparsed |= CONTEXT_MNT; > > > > > + } > > > > > + } > > > > > > > > Is there a reason why we need a dedicated sid variable as opposed to > > > > passing opt->context_sid as the parameter? For example: > > > > > > > > rc = parse_sid(NULL, s, &opts->context_sid); > > > > > > We don't need a dedicated sid variable. Should I make similar changes > > > in the second patch (get rid of the local sid variable in > > > selinux_sb_remount() and the *context_sid variables in > > > selinux_set_mnt_opts())? > > > > Yes please, I should have explicitly mentioned that. > > Actually, delayed_superblock_init() calls selinux_set_mnt_opts() with > mnt_opts == NULL, so there would have to be a lot of checks like > > if (opts && opts->fscontext_sid) { > > in the later parts of that function, which is kind of clunky. I can > still do it if you want though. I might be misunderstanding your concern, but in selinux_set_mnt_opts() all of the "opts->XXX" if-conditionals are protected by being inside an if-statement that checks to ensure "opts" is not NULL. Am I missing something? -- paul-moore.com