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;
From:   Steve Grubb <sgrubb@redhat.com>
To:     corbet@lwn.net, axboe@kernel.dk, agk@redhat.com,
        snitzer@redhat.com, ebiggers@kernel.org, tytso@mit.edu,
        paul@paul-moore.com, eparis@redhat.com, jmorris@namei.org,
        serge@hallyn.com, linux-audit@redhat.com,
        Deven Bowers <deven.desai@linux.microsoft.com>
Cc:     linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org,
        jannh@google.com, linux-fscrypt@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
        dm-devel@redhat.com
Subject: Re: [RFC PATCH v7 07/16] ipe: add auditing support
Date:   Tue, 02 Nov 2021 15:44:30 -0400
Message-ID: <1898302.usQuhbGJ8B@x2>
Organization: Red Hat
In-Reply-To: <8802b1ff-3028-642a-22c5-bc4896450a60@linux.microsoft.com>
References: <1634151995-16266-1-git-send-email-deven.desai@linux.microsoft.com> <2159283.iZASKD2KPV@x2> <8802b1ff-3028-642a-22c5-bc4896450a60@linux.microsoft.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hello,

On Friday, October 15, 2021 3:25:47 PM EDT Deven Bowers wrote:
> On 10/13/2021 1:02 PM, Steve Grubb wrote:
> > On Wednesday, October 13, 2021 3:06:26 PM EDT
> > deven.desai@linux.microsoft.com>=20
> > wrote:
> >> Users of IPE require a way to identify when and why an operation fails,
> >> allowing them to both respond to violations of policy and be notified
> >> of potentially malicious actions on their systens with respect to IPE
> >> itself.
> >=20
> > Would you mind sending examples of audit events so that we can see what
> > the end result is? Some people add them to the commit text. But we still
> > need to see what they look like.
>=20
> Sure, sorry. I=E2=80=99ll add them to the commit description (and the doc=
umentation
> patch at the end) for v8 =E2=80=93 In the interest of asynchronous feedba=
ck, I=E2=80=99ve
> copied the relevant examples:

Thanks for sending these. This helps.

=20
> AUDIT1420 IPE ctx_pid=3D229 ctx_op=3DEXECUTE ctx_hook=3DMMAP ctx_enforce=
=3D0
> ctx_comm=3D"grep" ctx_pathname=3D"/usr/lib/libc-2.23.so"
> ctx_ino=3D532 ctx_dev=3Dvda rule=3D"DEFAULT op=3DEXECUTE action=3DDENY"

Question...why do all of these have a ctx_  prefix? Is it possible to trigg=
er=20
an audit context so that the audit machinery collects all of this stuff in=
=20
it's own way? Which means you could drop everything execept op, hook,=20
enforce, rule, and action.

We also have a field dictionary here:
https://github.com/linux-audit/audit-documentation/blob/main/specs/fields/
field-dictionary.csv

which names the known fields and how they should be formatted. If there is =
a=20
collision where they are something else and cannot be in the same format,=20
then we make a new name and hopefully update the dictionary. For example, i=
f=20
you are collecting a process id, use pid and not ctx_pid so that it matches=
 a=20
known definition.

Also, I don't thnk these events can stand on their own. Who did this action=
?=20
You have the pid, but no uid, auid, or session_id.

Hope this helps...

=2DSteve

=20
> AUDIT1420 IPE ctx_pid=3D229 ctx_op=3DEXECUTE ctx_hook=3DMMAP ctx_enforce=
=3D0
> ctx_comm=3D"grep" ctx_pathname=3D"/usr/lib/libc-2.23.so"
> ctx_ino=3D532 ctx_dev=3Dvda rule=3D"DEFAULT action=3DDENY"
>=20
> AUDIT1420 IPE ctx_pid=3D253 ctx_op=3DEXECUTE ctx_hook=3DMMAP ctx_enforce=
=3D1
> ctx_comm=3D"anon" rule=3D"DEFAULT op=3DEXECUTE action=3DDENY"
>=20
> These three audit records represent various types of results after
> evaluating
> the trust of a resource. The first two differ in the rule that was
> matched in
> IPE's policy, the first being an operation-specific default, the second
> being
> a global default. The third is an example of what is audited when anonymo=
us
> memory is blocked (as there is no way to verify the trust of an anonymous
> page).
>=20
> The remaining three events, AUDIT_TRUST_POLICY_LOAD (1421),
> AUDIT_TRUST_POLICY_ACTIVATE (1422), and AUDIT_TRUST_STATUS (1423) have th=
is
> form:
>=20
> AUDIT1421 IPE policy_name=3D"my-policy" policy_version=3D0.0.0
> <hash_alg_name>=3D<hash>
> AUDIT1422 IPE policy_name=3D"my-policy" policy_version=3D0.0.0
> <hash_alg_name>=3D<hash>
> AUDIT1423 IPE enforce=3D1
>=20
> The 1421 (AUDIT_TRUST_POLICY_LOAD) event represents a new policy was load=
ed
> into the kernel, but not is not marked as the policy to enforce. The
>=20
> The 1422 (AUDIT_TRUST_POLICY_ACTIVATE) event represents a policy that was
> already loaded was made the enforcing policy.
>=20
> The 1423 (AUDIT_TRUST_STATUS) event represents a switch between
> permissive and
> enforce, it is added in 08/16 (the following patch)