lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 15 Oct 2021 12:25:47 -0700
From:   Deven Bowers <deven.desai@...ux.microsoft.com>
To:     Steve Grubb <sgrubb@...hat.com>, corbet@....net, axboe@...nel.dk,
        agk@...hat.com, snitzer@...hat.com, ebiggers@...nel.org,
        tytso@....edu, paul@...l-moore.com, eparis@...hat.com,
        jmorris@...ei.org, serge@...lyn.com, linux-audit@...hat.com
Cc:     linux-security-module@...r.kernel.org, linux-doc@...r.kernel.org,
        jannh@...gle.com, linux-fscrypt@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        dm-devel@...hat.com
Subject: Re: [RFC PATCH v7 07/16] ipe: add auditing support

On 10/13/2021 1:02 PM, Steve Grubb wrote:

> Hello,
>
> On Wednesday, October 13, 2021 3:06:26 PM EDT deven.desai@...ux.microsoft.com
> 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.
> 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.
>
> Thanks,
> -Steve

Sure, sorry. I’ll add them to the commit description (and the documentation
patch at the end) for v8 – In the interest of asynchronous feedback, I’ve
copied the relevant examples:

AUDIT1420 IPE ctx_pid=229 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=0
ctx_comm="grep" ctx_pathname="/usr/lib/libc-2.23.so"
ctx_ino=532 ctx_dev=vda rule="DEFAULT op=EXECUTE action=DENY"

AUDIT1420 IPE ctx_pid=229 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=0
ctx_comm="grep" ctx_pathname="/usr/lib/libc-2.23.so"
ctx_ino=532 ctx_dev=vda rule="DEFAULT action=DENY"

AUDIT1420 IPE ctx_pid=253 ctx_op=EXECUTE ctx_hook=MMAP ctx_enforce=1
ctx_comm="anon" rule="DEFAULT op=EXECUTE action=DENY"

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 anonymous
memory is blocked (as there is no way to verify the trust of an anonymous
page).

The remaining three events, AUDIT_TRUST_POLICY_LOAD (1421),
AUDIT_TRUST_POLICY_ACTIVATE (1422), and AUDIT_TRUST_STATUS (1423) have this
form:

AUDIT1421 IPE policy_name="my-policy" policy_version=0.0.0 
<hash_alg_name>=<hash>
AUDIT1422 IPE policy_name="my-policy" policy_version=0.0.0 
<hash_alg_name>=<hash>
AUDIT1423 IPE enforce=1

The 1421 (AUDIT_TRUST_POLICY_LOAD) event represents a new policy was loaded
into the kernel, but not is not marked as the policy to enforce. The

The 1422 (AUDIT_TRUST_POLICY_ACTIVATE) event represents a policy that was
already loaded was made the enforcing policy.

The 1423 (AUDIT_TRUST_STATUS) event represents a switch between 
permissive and
enforce, it is added in 08/16 (the following patch)

Powered by blists - more mailing lists