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;
IronPort-PHdr: =?us-ascii?q?9a23=3AyIitsxPqiYkiP7VErY4l6mtXPHoupqn0MwgJ65?=
 =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3kfAQIGe7vVDkeeQuKflCiQM4peE5XYFdpEEFx?=
 =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNEXbv3n36DkVAB?=
 =?us-ascii?q?i5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?=
 =?us-ascii?q?DO5HBPfrdb?=
From:   "Daniel Walker (danielwa)" <danielwa@cisco.com>
To:     Paul Moore <paul@paul-moore.com>
CC:     Eric Paris <eparis@redhat.com>,
        "Phil Zhang (xuanyzha)" <xuanyzha@cisco.com>,
        "xe-linux-external(mailer list)" <xe-linux-external@cisco.com>,
        "linux-audit@redhat.com" <linux-audit@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] audit: show (grand)parents information of an audit
 context
Thread-Topic: [PATCH 2/2] audit: show (grand)parents information of an audit
 context
Thread-Index: AQHW+l5c7p0UJchtWEm2GCMjkqfQVw==
Date:   Wed, 3 Feb 2021 18:57:04 +0000
Message-ID: <20210203185700.GK3710@zorba>
References: <20210202212930.18845-2-danielwa@cisco.com>
 <CAHC9VhTo_aTTsS5W-+AJe+RrNG4yL3_TbfOKZhZfpjg0QkkZUQ@mail.gmail.com>
In-Reply-To: <CAHC9VhTo_aTTsS5W-+AJe+RrNG4yL3_TbfOKZhZfpjg0QkkZUQ@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Mutt/1.9.4 (2018-02-28)
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8E62BA3099DF324FB2947520907E43F9@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3389ea2e-7202-447a-0b38-08d8c8757f91
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2021 18:57:04.8442
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CiVcqMk9db43+HcVKndE6mz/cxGYSNCHtZRk/2ZSz76ueXNlBfUNhuLHL9qWMytFcqSCDoUwuDNe3rY809SVXg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2950
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 02, 2021 at 04:44:47PM -0500, Paul Moore wrote:
> On Tue, Feb 2, 2021 at 4:29 PM Daniel Walker <danielwa@cisco.com> wrote:
> > From: Phil Zhang <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=3DPARENT msg=3Daudit(1610548241.033:255): subj=3Droot:unconfin=
ed_r:unconfined_t:s0-s0:c0.c1023  cmdline=3D"-bash"
> >     type=3DPARENT msg=3Daudit(1610548241.033:255): subj=3Dsystem_u:syst=
em_r:sshd_t:s0-s0:c0.c1023        cmdline=3D"sshd: root@pts/0"
> >     type=3DPARENT msg=3Daudit(1610548241.033:255): subj=3Dsystem_u:syst=
em_r:sshd_t:s0-s0:c0.c1023        cmdline=3D"/tmp/sw/rp/0/0/rp_security/mou=
nt/usr/sbin/sshd
> >     type=3DPARENT msg=3Daudit(1610548241.033:255): subj=3Dsystem_u:syst=
em_r:init_t:s0                    cmdline=3D"/init"
> >     type=3DPARENT msg=3Daudit(1610548241.033:255): subj=3Dsystem_u:syst=
em_r:kernel_t:s0
> >     ...
> >
> > Cc: xe-linux-external@cisco.com
> > Signed-off-by: Phil Zhang <xuanyzha@cisco.com>
> > Signed-off-by: Daniel Walker <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(-)
>=20
> 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.
=20
That's why the patch was create to better understand the system.

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

We have a very complex and constantly changing system, and we use shell scr=
ipts
some of the time. If a shell script triggers an AVC it will typically show =
the
tool called instead of the shell script which triggered calling the tool.

We do have audit enabled in production systems, and I think we collect thes=
e
logs in case of issues on the production system. Phil is better to address =
this.

We're willing to try alternatives like what you suggested above.

Daniel