From: Lenny Bruzenak <lenny@magitekltd.com>
To: linux-audit@redhat.com
Subject: Re: [PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions
Date: Wed, 30 May 2018 19:46:24 -0500 [thread overview]
Message-ID: <adc94d4b-0aaf-d9ec-ba8f-3b044ff6f1c4@magitekltd.com> (raw)
In-Reply-To: <CAHC9VhQrYqK2fTOc5uZeNRx9-RAZSgkuAuW0r1BoHGrpzTyL5A@mail.gmail.com>
On 05/30/2018 06:54 PM, Paul Moore wrote:
...
> Finally, since you probably haven't followed all of the discussion
> around associating records into a single event, I wanted to give you
> my side of the story (if you don't care, you can simply skip the rest
> of this email). Currently an audit "event" can consist of multiple
> audit "records"; these records can contain PATH information, SYSCALL
> information, SELinux AVC information, as well as INTEGRITY_PCR
> information. The current kernel code does a poor job of associating
> some of these record types, which can make a single user action look
> like multiple audit events. For example, a single user action/event
> (writing a new IMA policy) could result in multiple audit "events"
> because the SYSCALL record for the write() syscall is not associated
> with the INTEGRITY_POLICY_RULE record; this is bogus because the write
> syscall is inherently linked with the IMA policy update. Keeping the
> records as separate audit "events" is not only conceptually odd, it is
> misleading.
A vote of support from the user side; thanks Paul for this. The
misleading part of having multiple events for what is conceptually a
unitary event makes life really hard on guys like me trying to explain
to security people what happened when. So while I understand it can be
challenging to associate those events in the kernel, particularly when
they occur at spaced times, trying to patch those together on the
analysis side is problematic too (which I know you well understand). So
- your effort to keep these these records tied to one event is very much
appreciated!
LCB
--
Lenny Bruzenak
MagitekLTD
next prev parent reply other threads:[~2018-05-31 0:46 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 20:10 [PATCH 0/8] IMA: work on audit records produced by IMA Stefan Berger
2018-05-24 20:10 ` [PATCH 1/8] ima: Call audit_log_string() rather than logging it untrusted Stefan Berger
2018-05-29 20:29 ` Paul Moore
2018-05-24 20:10 ` [PATCH 2/8] ima: Use audit_log_format() rather than audit_log_string() Stefan Berger
2018-05-29 20:31 ` Paul Moore
2018-05-24 20:11 ` [PATCH 3/8] audit: Implement audit_log_tty() Stefan Berger
2018-05-29 21:07 ` Paul Moore
2018-05-30 19:46 ` Stefan Berger
2018-05-24 20:11 ` [PATCH 4/8] audit: Allow others to call audit_log_d_path_exe() Stefan Berger
2018-05-29 21:18 ` Paul Moore
2018-05-24 20:11 ` [PATCH 5/8] integrity: Add exe= and tty= before res= to integrity audits Stefan Berger
2018-05-29 21:19 ` Paul Moore
2018-05-29 21:35 ` Steve Grubb
2018-05-29 21:47 ` Paul Moore
2018-05-29 22:58 ` Mimi Zohar
2018-05-30 13:04 ` Mimi Zohar
2018-05-30 21:15 ` Paul Moore
2018-05-30 12:17 ` Stefan Berger
2018-05-30 21:14 ` Paul Moore
2018-05-24 20:11 ` [PATCH 6/8] integrity: Factor out common part of integrity_audit_msg() Stefan Berger
2018-05-29 21:32 ` Steve Grubb
2018-05-30 13:04 ` Stefan Berger
2018-05-24 20:11 ` [PATCH 7/8] ima: Do not audit if CONFIG_INTEGRITY_AUDIT is not set Stefan Berger
2018-05-24 20:11 ` [PATCH 8/8] ima: Differentiate auditing policy rules from "audit" actions Stefan Berger
2018-05-29 21:30 ` Steve Grubb
2018-05-30 13:54 ` Stefan Berger
2018-05-30 15:15 ` Steve Grubb
2018-05-30 15:25 ` Stefan Berger
2018-05-30 16:27 ` Steve Grubb
2018-05-30 19:54 ` Stefan Berger
2018-05-30 21:24 ` Paul Moore
2018-05-30 21:49 ` Stefan Berger
2018-05-30 22:00 ` Mimi Zohar
2018-05-30 22:15 ` Stefan Berger
2018-05-30 22:41 ` Mimi Zohar
2018-05-30 23:54 ` Paul Moore
2018-05-31 0:46 ` Lenny Bruzenak [this message]
2018-05-31 15:51 ` Paul Moore
2018-05-30 12:49 ` Richard Guy Briggs
2018-05-30 12:55 ` Steve Grubb
2018-05-30 13:08 ` Stefan Berger
2018-05-30 21:22 ` Paul Moore
2018-05-30 21:38 ` Stefan Berger
2018-05-30 23:34 ` Richard Guy Briggs
2018-06-01 20:00 ` Stefan Berger
2018-06-01 20:13 ` Paul Moore
2018-06-01 20:21 ` Paul Moore
2018-06-01 20:50 ` Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adc94d4b-0aaf-d9ec-ba8f-3b044ff6f1c4@magitekltd.com \
--to=lenny@magitekltd.com \
--cc=linux-audit@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox