From: "Phil Zhang (xuanyzha)" <xuanyzha@cisco.com>
To: "paul@paul-moore.com" <paul@paul-moore.com>,
"Daniel Walker (danielwa)" <danielwa@cisco.com>
Cc: "polaris-selinux-dev\(mailer list\)"
<polaris-selinux-dev@cisco.com>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xe-linux-external\(mailer list\)" <xe-linux-external@cisco.com>
Subject: Re: [PATCH 2/2] audit: show (grand)parents information of an audit context
Date: Tue, 2 Feb 2021 21:55:12 +0000 [thread overview]
Message-ID: <6c8ba313f01ad7205176b33bb35e066e21c85936.camel@cisco.com> (raw)
In-Reply-To: <CAHC9VhTo_aTTsS5W-+AJe+RrNG4yL3_TbfOKZhZfpjg0QkkZUQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3161 bytes --]
Daniel,
As far as I know Victor did not attempt to upstream his UBACKTRACE feature for audit.
Following Paul's point, maybe this is only useful in our internal use. Tracing fork/exec
in userland(auditctl) has been the way we are doing it. but we cannot afford to run it in
regression tests and valueable information was thus not captured and it's difficult for
folks to reproduce the issue.
Phil
On Tue, 2021-02-02 at 16:44 -0500, Paul Moore wrote:
On Tue, Feb 2, 2021 at 4:29 PM Daniel Walker <
<mailto:danielwa@cisco.com>
danielwa@cisco.com
> wrote:
From: Phil Zhang <
<mailto:xuanyzha@cisco.com>
xuanyzha@cisco.com
>
To ease the root cause analysis of SELinux AVCs, this new feature
traverses task structs to iteratively find all parent processes
starting with the denied process and ending at the kernel. Meanwhile,
it prints out the command lines and subject contexts of those parents.
This provides developers a clear view of how processes were spawned
and where transitions happened, without the need to reproduce the
issue and manually audit interesting events.
Example on bash over ssh:
$ runcon -u system_u -r system_r -t polaris_hm_t ls
...
type=PARENT msg=audit(1610548241.033:255): subj=root:unconfined_r:unconfined_t:s0-s0:c0.c1023 cmdline="-bash"
type=PARENT msg=audit(1610548241.033:255): subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 cmdline="sshd: root@pts/0"
type=PARENT msg=audit(1610548241.033:255): subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 cmdline="/tmp/sw/rp/0/0/rp_security/mount/usr/sbin/sshd
type=PARENT msg=audit(1610548241.033:255): subj=system_u:system_r:init_t:s0 cmdline="/init"
type=PARENT msg=audit(1610548241.033:255): subj=system_u:system_r:kernel_t:s0
...
Cc:
<mailto:xe-linux-external@cisco.com>
xe-linux-external@cisco.com
Signed-off-by: Phil Zhang <
<mailto:xuanyzha@cisco.com>
xuanyzha@cisco.com
>
Signed-off-by: Daniel Walker <
<mailto:danielwa@cisco.com>
danielwa@cisco.com
>
---
include/uapi/linux/audit.h | 5 ++-
init/Kconfig | 7 +++++
kernel/audit.c | 3 +-
kernel/auditsc.c | 64 ++++++++++++++++++++++++++++++++++++++
4 files changed, 77 insertions(+), 2 deletions(-)
This is just for development/testing of SELinux policy, right? It
seems like this is better done in userspace to me through a
combination of policy analysis and just understanding of how your
system is put together.
If you really need this information in the audit log for some
production use, it seems like you could audit the various
fork()/exec() syscalls to get an understanding of the various process
(sub)trees on the system. It would require a bit of work to sift
through the audit log and reconstruct the events that led to a process
being started, and generating the AVC you are interested in debugging,
but folks who live The Audit Life supposedly do this sort of thing a
lot (this sort of thing being tracing a process/session).
[-- Attachment #1.2: Type: text/html, Size: 4422 bytes --]
[-- Attachment #2: Type: text/plain, Size: 102 bytes --]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-02-02 21:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 21:29 [PATCH 2/2] audit: show (grand)parents information of an audit context Daniel Walker
2021-02-02 21:44 ` Paul Moore
2021-02-02 21:55 ` Phil Zhang (xuanyzha) [this message]
2021-02-03 18:57 ` Daniel Walker (danielwa)
2021-02-03 19:11 ` Phil Zhang (xuanyzha)
2021-02-03 6:24 ` kernel test robot
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=6c8ba313f01ad7205176b33bb35e066e21c85936.camel@cisco.com \
--to=xuanyzha@cisco.com \
--cc=danielwa@cisco.com \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=polaris-selinux-dev@cisco.com \
--cc=xe-linux-external@cisco.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;
as well as URLs for NNTP newsgroup(s).