[PATCH 2/2] audit: show (grand)parents information of an audit context

Phil Zhang (xuanyzha) xuanyzha at cisco.com
Tue Feb 2 21:55:12 UTC 2021


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 at cisco.com>

danielwa at cisco.com

> wrote:

From: Phil Zhang <

<mailto:xuanyzha at cisco.com>

xuanyzha at 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 at 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 at cisco.com>

xe-linux-external at cisco.com


Signed-off-by: Phil Zhang <

<mailto:xuanyzha at cisco.com>

xuanyzha at cisco.com

>

Signed-off-by: Daniel Walker <

<mailto:danielwa at cisco.com>

danielwa at 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).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20210202/460ac5fa/attachment.htm>


More information about the Linux-audit mailing list