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;
MIME-Version: 1.0
References: <20200604163243.2575-1-nramas@linux.microsoft.com>
 <1591382782.5816.36.camel@linux.ibm.com> <CAHC9VhS-EP=Kk3GKRzAGAYa5mqupkLQCHz_m_DgoAKRWcSTgLA@mail.gmail.com>
 <8dfb3fa6-5c1f-d644-7d21-72a9448c52cc@linux.microsoft.com>
In-Reply-To: <8dfb3fa6-5c1f-d644-7d21-72a9448c52cc@linux.microsoft.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Fri, 5 Jun 2020 16:49:32 -0400
Message-ID: <CAHC9VhS8gmrWxt75aHAE16PWAay7sUrffZiT0A8VLugwexK4Uw@mail.gmail.com>
Subject: Re: [PATCH] IMA: Add log statements for failure conditions
To:     Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Cc:     Mimi Zohar <zohar@linux.ibm.com>, linux-integrity@vger.kernel.org,
        tusharsu@linux.microsoft.com, linux-kernel@vger.kernel.org,
        linux-audit@redhat.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Jun 5, 2020 at 3:54 PM Lakshmi Ramasubramanian
<nramas@linux.microsoft.com> wrote:
> On 6/5/20 12:37 PM, Paul Moore wrote:
>
> > If it's audit related, it's generally best to CC the linux-audit list,
> > not just me (fixed).
> >
> > It's not clear to me what this pr_err() is trying to indicate other
> > than *something* failed.  Can someone provide some more background on
> > this message?
>
> process_buffer_measurement() is currently used to measure
> "kexec command line", "keys", and "blacklist-hash". If there was any
> error in the measurement, this pr_err() will indicate which of the above
> measurement failed and the related error code.
>
> Please let me know if you need more info on this one.

That helps, thank you.

> Since a pr_xyz() call was already present, I just wanted to change the
> log level to keep the code change to the minimum. But if audit log is
> the right approach for this case, I'll update.

Generally we reserve audit for things that are required for various
security certifications and/or "security relevant".  From what you
mentioned above, it seems like this would fall into the second
category if not the first.

Looking at your patch it doesn't look like you are trying to record
anything special so you may be able to use the existing
integrity_audit_msg(...) helper.  Of course then the question comes
down to the audit record type (the audit_msgno argument), the
operation (op), and the comm/cause (cause).

Do you feel that any of the existing audit record types are a good fit for this?

-- 
paul moore
www.paul-moore.com