Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1169525pxk; Mon, 31 Aug 2020 11:41:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysT5Fz+cXPnKD/sPWctwzl9fxpLq9CLK4ptrs3jFiOLlqejpEq7+KLA0CQEyqe7YOVPdPa X-Received: by 2002:a17:907:2115:: with SMTP id qn21mr2209278ejb.278.1598899311154; Mon, 31 Aug 2020 11:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598899311; cv=none; d=google.com; s=arc-20160816; b=AJq6UioawYonufh+0+LNpuDElpYdDO5pQygo4ilknGXP15zfeBc3LDsKmABOsNWXrt 4AzopEeaDUNK6ODnsTOeCl7DwHeggPifchsYYGPgnAjdbk2FODu8BXqqcGyelqxi8J3n 1bnLB61SzG4Jciw1pKADFDRnj1vOJRxB/sbJ3S+nMKBw5sFCVDdYtsNBJ3hOAGWc3J4S /dQLLsOFSE5193zJUPsv13llHYE59za8BWRqvHlbcleROeWn4yMMzWyGuf73ODLHmk2U yTRiRvbHbFihQJRf1DxwNGOZIHIw1YaIeK0xuFw+5f7i40D1YCwXpiiO0HXAtxDUBb58 omXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Q2tcN9Jz0h7kw1m7OiNmzbCBKujbmSV8MqHohL1aMxc=; b=OZkubxEn8ZpPeXWUmeEBOT3mqzy8ijJxDfOgGoKZTQBY2zKwV0P3yao+ZPa1EcZcoF iU+y5z8+Vb1FapscSUb9EaQw/E+At6d6Q+3FM0dawoSYF05IZHnFskYvtNkyltmUOsmx WCdmQr8Mu5hoppQznfc9+TMPrNestMH+2RzHx8XlN91esaX82Px5HKb0bCtCNA5y+ehp EuMEQX+IEPUQUaHjrYye81KJLurwlzAekZwgrMABzZh7ayUDtmQhfTSJYoBJoQSvq0sU U1tfDui/yUIF0Ep9xGHgMyND+8pKuaHLMWe9trhX6tBldUrBTAPjOFzTm4QOVJGqrJl9 Z97Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=okkSFCeO; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s5si5637276ejz.589.2020.08.31.11.41.28; Mon, 31 Aug 2020 11:41:51 -0700 (PDT) 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=@gmail.com header.s=20161025 header.b=okkSFCeO; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728135AbgHaOrY (ORCPT + 99 others); Mon, 31 Aug 2020 10:47:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726384AbgHaOrP (ORCPT ); Mon, 31 Aug 2020 10:47:15 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AFFCC061573; Mon, 31 Aug 2020 07:47:14 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id g96so2946895otb.12; Mon, 31 Aug 2020 07:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q2tcN9Jz0h7kw1m7OiNmzbCBKujbmSV8MqHohL1aMxc=; b=okkSFCeO2nLOMIkvoDn5wLrmrRFbpUKUqcypUHRgryOCdvmz3bPyt7lDX0PFnuYEhO 6c1MpCfws1lykdrr5sGQGnJ3t2/jkaOafYInME7Uaowdrhymh8jFoBia/4swJJohXsyq QgGEF/yDCmAs0V0u9D3NiJEDrjYd9qH3H6Co+ZRgTYBFxrqUeC8fQ+D1V+PmFF66zVu2 pMJrZ0kfwK9NJM9tJ+lwaDcSSBJKkFv6wWGhPOB3InIaQTDMNjD2B6KBwy+kLr52z2ux AVdRnxjK4d1VkohanZCV2N5dT0GVBilRt+j/7o/mxVGHgM2S03t5opG2vu74RxPAaz9+ 5YgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q2tcN9Jz0h7kw1m7OiNmzbCBKujbmSV8MqHohL1aMxc=; b=SdjyGfHfLkTiniboi0XyCntDZA9EHvE1FvqlVkrwMOsyifVZlhmaTLatpqb65I9t5i KKtjeT3GTzakiqUzlF1vkcf4Ug/I+sKUsHwZUyaisnJloUhWMUK3KkBt/AXabWO2cZ/g UVKnhl+c7Jo6lAwrDbRnNuhPW8PWy8p7yRmH4iUjhPGppSqLVhQaGqrm7ud5wF/H/BEZ weuk3HhJ1Skpv4bqMhR8nG5hLOVgTLiiW3guyYGWOq7DLLm9pK7efEiEFbQZkwUisIi7 7Dm9YbFx8utYYf2aGLe3k2ytCwIvs672pVbgIJOGMGaM4DnawboJrsoGZPAGZJO7yZy1 MPyA== X-Gm-Message-State: AOAM5317WEQUhprz+kgRZFhdAZypa728ybuXV/6gm2pt5raYtcpA6O2U dJbIYb9EXWvoi5MfFzRsm6zHOTUeY9WDzIjin1g= X-Received: by 2002:a05:6830:1258:: with SMTP id s24mr1192602otp.162.1598885233434; Mon, 31 Aug 2020 07:47:13 -0700 (PDT) MIME-Version: 1.0 References: <20200822010018.19453-1-nramas@linux.microsoft.com> <418618c4-a0c6-6b28-6718-2726a29b83c5@linux.microsoft.com> <07854807-c495-b7e5-fc44-26d78ff14f1b@linux.microsoft.com> In-Reply-To: From: Stephen Smalley Date: Mon, 31 Aug 2020 10:47:02 -0400 Message-ID: Subject: Re: [PATCH] SELinux: Measure state and hash of policy using IMA To: Lakshmi Ramasubramanian Cc: Paul Moore , Ondrej Mosnacek , Mimi Zohar , Casey Schaufler , Tyler Hicks , tusharsu@linux.microsoft.com, Sasha Levin , James Morris , linux-integrity@vger.kernel.org, SElinux list , LSM List , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 26, 2020 at 8:51 AM Stephen Smalley wrote: > > On Tue, Aug 25, 2020 at 4:49 PM Lakshmi Ramasubramanian > wrote: > > > > On 8/24/20 3:18 PM, Paul Moore wrote: > > > > Hi Paul, > > > > >>>>> Is Ondrej's re-try approach I need to use to workaround policy reload issue? > > >>>> > > >>>> No, I think perhaps we should move the mutex to selinux_state instead > > >>>> of selinux_fs_info. selinux_fs_info has a pointer to selinux_state so > > >>>> it can then use it indirectly. Note that your patches are going to > > >>>> conflict with other ongoing work in the selinux next branch that is > > >>>> refactoring policy load and converting the policy rwlock to RCU. > > >>> > > >>> Yeah, and I'm experimenting with a patch on top of Stephen's RCU work > > >>> that would allow you to do this in a straightforward way without even > > >>> messing with the fsi->mutex. My patch may or may not be eventually > > >>> committed, but either way I'd recommend holding off on this for a > > >>> while until the dust settles around the RCU conversion. > > >> > > >> I can make the SELinux\IMA changes in "selinux next branch" taking > > >> dependencies on Stephen's patches + relevant IMA patches. > > > > > > I know it can be frustrating to hear what I'm about to say, but the > > > best option is probably just to wait a little to let things settle in > > > the SELinux -next branch. There is a lot of stuff going on right now > > > with patches flooding in (at least "flooding" from a SELinux kernel > > > development perspective) and we/I've haven't gotten through all of > > > them yet. > > > > > > > Could you please let me know when the current set of changes in SELinux > > next branch would be completed and be ready to take new changes? > > > > I mean, roughly - would it be a month from now or you expect that to > > take longer? > > I can't speak for Paul but I would expect it to be sooner rather than > later. Ondrej has some follow ups on top of my policy rcu conversion > but then it should be good to go. I think the major changes are now merged although there are still a couple of changes coming from Ondrej that could affect your code. For your purposes, the important things to note are: 1) The mutex has moved from selinux_fs_info to selinux_state and is now named policy_mutex. You will need to take it around your call to security_read_policy_kernel(). 2) security_policydb_len() was removed and security_read_policy() just directly reads the policydb len. You can do the same from your security_read_policy_kernel() variant. 3) Ondrej has a pending change to move the policycap[] array from selinux_state to selinux_policy so that it can be atomically updated with the policy. 4) Ondrej has a pending change to eliminate the separate initialized boolean from selinux_state and just test whether selinux_state.policy is non-NULL but as long as you are using selinux_initialized() to test, your code should be unaffected.