On Tuesday, June 16, 2020 3:53:40 PM EDT Mimi Zohar wrote:
> On Tue, 2020-06-16 at 11:55 -0400, Steve Grubb wrote:
> > On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote:
> > > On 6/16/20 8:29 AM, Steve Grubb wrote:
> > > > The idea is a good idea, but you're assuming that
On Tue, 2020-06-16 at 11:55 -0400, Steve Grubb wrote:
> On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote:
> > On 6/16/20 8:29 AM, Steve Grubb wrote:
> > > The idea is a good idea, but you're assuming that "result" is always
> > > errno. That was probably true
On Tuesday, June 16, 2020 11:43:31 AM EDT Lakshmi Ramasubramanian wrote:
> On 6/16/20 8:29 AM, Steve Grubb wrote:
> > The idea is a good idea, but you're assuming that "result" is always
> > errno. That was probably true originally, but isn't now. For
> > example,
On 6/16/20 8:29 AM, Steve Grubb wrote:
The idea is a good idea, but you're assuming that "result" is always
errno. That was probably true originally, but isn't now. For
example, ima_appraise_measurement() calls xattr_verify(), which
compares the security.ima hash with the calculated file
On Monday, June 15, 2020 6:58:13 PM EDT Paul Moore wrote:
> On Mon, Jun 15, 2020 at 6:23 PM Steve Grubb wrote:
> > On Friday, June 12, 2020 3:50:14 PM EDT Lakshmi Ramasubramanian wrote:
> > > On 6/12/20 12:25 PM, Mimi Zohar wrote:
> > > > The idea is a good idea, but you're assuming that "result"
On Mon, Jun 15, 2020 at 6:23 PM Steve Grubb wrote:
> On Friday, June 12, 2020 3:50:14 PM EDT Lakshmi Ramasubramanian wrote:
> > On 6/12/20 12:25 PM, Mimi Zohar wrote:
> > > The idea is a good idea, but you're assuming that "result" is always
> > > errno. That was probably true originally, but
On Friday, June 12, 2020 3:50:14 PM EDT Lakshmi Ramasubramanian wrote:
> On 6/12/20 12:25 PM, Mimi Zohar wrote:
> > The idea is a good idea, but you're assuming that "result" is always
> > errno. That was probably true originally, but isn't now. For
> > example, ima_appraise_measurement() calls
On 6/12/20 12:25 PM, Mimi Zohar wrote:
The idea is a good idea, but you're assuming that "result" is always
errno. That was probably true originally, but isn't now. For
example, ima_appraise_measurement() calls xattr_verify(), which
compares the security.ima hash with the calculated file
On Wed, 2020-06-10 at 17:03 -0700, Lakshmi Ramasubramanian wrote:
> Error code is not included in the audit messages logged by
> the integrity subsystem. Add a new field namely "errno" in
> the audit message and set the value to the error code passed
> to integrity_audit_msg() in the "result"
On 6/10/20 6:45 PM, Paul Moore wrote:
Hi Paul,
I'm sorry I didn't get a chance to mention this before you posted this
patch, but for the past several years we have been sticking with a
policy of only adding new fields to the end of existing records;
please adjust this patch accordingly.
Error code is not included in the audit messages logged by
the integrity subsystem. Add a new field namely "errno" in
the audit message and set the value to the error code passed
to integrity_audit_msg() in the "result" parameter.
Sample audit message:
[6.284329] audit: type=1804
On Wed, Jun 10, 2020 at 9:58 PM Lakshmi Ramasubramanian
wrote:
> On 6/10/20 6:45 PM, Paul Moore wrote:
>
> Hi Paul,
>
> > I'm sorry I didn't get a chance to mention this before you posted this
> > patch, but for the past several years we have been sticking with a
> > policy of only adding new
On Wed, Jun 10, 2020 at 8:04 PM Lakshmi Ramasubramanian
wrote:
>
> Error code is not included in the audit messages logged by
> the integrity subsystem. Add a new field namely "errno" in
> the audit message and set the value to the error code passed
> to integrity_audit_msg() in the "result"
13 matches
Mail list logo
