linux-kernel - Re: [PATCH] audit: add containerid support for IMA-audit

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:   Mon, 21 May 2018 12:58:28 -0400
From:   Steve Grubb <sgrubb@...hat.com>
To:     Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     Richard Guy Briggs <rgb@...hat.com>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        containers@...ts.linux-foundation.org,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, paul@...l-moore.com
Subject: Re: [PATCH] audit: add containerid support for IMA-audit

On Thursday, May 17, 2018 10:18:13 AM EDT Stefan Berger wrote:
> > audit_log_container_info() then releasing the local context.  This
> > version of the record has additional concerns covered here:
> > https://github.com/linux-audit/audit-kernel/issues/52
> 
> Following the discussion there and the concern with breaking user space,
> how can we split up the AUDIT_INTEGRITY_RULE that is used in
> ima_audit_measurement() and ima_parse_rule(), without 'breaking user
> space'?
> 
> A message produced by ima_parse_rule() looks like this here:
> 
> type=INTEGRITY_RULE msg=audit(1526566213.870:305): action="dont_measure"
> fsmagic="0x9fa0" res=1

Why is action and fsmagic being logged as untrusted strings? Untrusted 
strings are used when an unprivileged user can affect the contents of the 
field such as creating a file with space or special characters in the name.

Also, subject and object information is missing. Who loaded this rule?

> in contrast to that an INTEGRITY_PCR record type:
> 
> type=INTEGRITY_PCR msg=audit(1526566235.193:334): pid=1615 uid=0 auid=0
> ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> op="invalid_pcr" cause="open_writers" comm="scp"
> name="/var/log/audit/audit.log" dev="dm-0" ino=1962625 res=1

Why is op & cause being logged as an untrusted string? This also has 
incomplete subject information.

> Should some of the fields from INTEGRITY_PCR also appear in
> INTEGRITY_RULE? If so, which ones? 

pid, uid, auid, tty, session, subj, comm, exe, res.  <- these are required to 
be searchable

> We could probably refactor the current  integrity_audit_message() and have
> ima_parse_rule() call into it to get those fields as well. I suppose adding
> new fields to it wouldn't be considered breaking user space?

The audit user space utilities pretty much expects those fields in that order 
for any IMA originating events. You can add things like op or cause before 
that. The reason why you can do that is those additional fields are not 
required to be searchable by common criteria.

-Steve