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;
Message-ID: <3679df359c35561f5bf6608911f96cc0292c7854.camel@linux.ibm.com>
Subject: Re: [PATCH 2/2] SELinux: Measure state and hash of policy using IMA
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Stephen Smalley <stephen.smalley.work@gmail.com>,
        Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Cc:     Casey Schaufler <casey@schaufler-ca.com>,
        Tyler Hicks <tyhicks@linux.microsoft.com>,
        tusharsu@linux.microsoft.com, sashal@kernel.org,
        James Morris <jmorris@namei.org>,
        linux-integrity@vger.kernel.org,
        SElinux list <selinux@vger.kernel.org>,
        LSM List <linux-security-module@vger.kernel.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        paul Moore <paul@paul-moore.com>
Date:   Mon, 17 Aug 2020 17:31:27 -0400
In-Reply-To: <CAEjxPJ7uWee5jjALtQ3azMvKRMk8pxFiYByWmYVhjgJiMNZ8ww@mail.gmail.com>
References: <20200813170707.2659-1-nramas@linux.microsoft.com>
         <20200813170707.2659-3-nramas@linux.microsoft.com>
         <5f738fd8-fe28-5358-b3d8-b671b45caa7f@gmail.com>
         <7315b7e8-2c53-2555-bc2e-aae42e16aaa2@linux.microsoft.com>
         <CAEjxPJ6sZdm2w=bbkL0uJyEkHw0gCT_y812WQBZPtLCJzO6r3A@mail.gmail.com>
         <e935c06f-09e2-a2f7-f97f-768bc017f477@linux.microsoft.com>
         <CAEjxPJ7uWee5jjALtQ3azMvKRMk8pxFiYByWmYVhjgJiMNZ8ww@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2020-08-13 at 14:13 -0400, Stephen Smalley wrote:
> On Thu, Aug 13, 2020 at 2:03 PM Lakshmi Ramasubramanian
> <nramas@linux.microsoft.com> wrote:
> > On 8/13/20 10:58 AM, Stephen Smalley wrote:
> > > On Thu, Aug 13, 2020 at 1:52 PM Lakshmi Ramasubramanian
> > > <nramas@linux.microsoft.com> wrote:
> > > > On 8/13/20 10:42 AM, Stephen Smalley wrote:
> > > > 
> > > > > > diff --git a/security/selinux/measure.c b/security/selinux/measure.c
> > > > > > new file mode 100644
> > > > > > index 000000000000..f21b7de4e2ae
> > > > > > --- /dev/null
> > > > > > +++ b/security/selinux/measure.c
> > > > > > @@ -0,0 +1,204 @@
> > > > > > +static int selinux_hash_buffer(void *buf, size_t buf_len,
> > > > > > +                   void **buf_hash, int *buf_hash_len)
> > > > > > +{
> > > > > > +    struct crypto_shash *tfm;
> > > > > > +    struct shash_desc *desc = NULL;
> > > > > > +    void *digest = NULL;
> > > > > > +    int desc_size;
> > > > > > +    int digest_size;
> > > > > > +    int ret = 0;
> > > > > > +
> > > > > > +    tfm = crypto_alloc_shash("sha256", 0, 0);
> > > > > > +    if (IS_ERR(tfm))
> > > > > > +        return PTR_ERR(tfm);
> > > > > Can we make the algorithm selectable via kernel parameter and/or writing
> > > > > to a new selinuxfs node?
> > > > 
> > > > I can add a kernel parameter to select this hash algorithm.
> > > 
> > > Also can we provide a Kconfig option for the default value like IMA does?
> > > 
> > 
> > Would we need both - Kconfig and kernel param?
> > 
> > The other option is to provide an IMA function to return the current
> > hash algorithm used for measurement. That way a consistent hash
> > algorithm can be employed by both IMA and the callers. Would that be better?
> 
> This is why I preferred just passing the serialized policy buffer to
> IMA and letting it handle the hashing.  But apparently that approach
> wouldn't fly.  IMA appears to support both a Kconfig option for
> selecting a default algorithm and a kernel parameter for overriding
> it.  I assume the idea is that the distros can pick a reasonable
> default and then the end users can override that if they have specific
> requirements.  I'd want the same for SELinux.  If IMA is willing to
> export its hash algorithm to external components, then I'm willing to
> reuse that but not sure if that's a layering violation.

With the new ima_measure_critical_data() hook, I agree with you and
Casey it doesn't make sense for each caller to have to write their own
function.  Casey suggested exporting IMA's hash function or defining a
new common hash function.   There's nothing specific to IMA.  Should
the common hash function be prefixed with "security_"?

Like when we add a new security hook call, the new LSM call is separate
from any other change.   Please break up this patch with the SELinux
specific pieces separated from the ima_measure_critical_data() call as
much as possible.

thanks,

Mimi