From: Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux-Audit Mailing List
<linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-integrity
<linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Mimi Zohar
<zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH] audit: add containerid support for IMA-audit
Date: Tue, 22 May 2018 10:12:10 -0400 [thread overview]
Message-ID: <7716958.jNg3Sb0t5f__32342.1664107174$1526998235$gmane$org@x2> (raw)
In-Reply-To: <20180522134346.b3bm7ndfjjchju3b-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
On Tuesday, May 22, 2018 9:43:46 AM EDT Richard Guy Briggs wrote:
> On 2018-05-21 17:57, Stefan Berger wrote:
> > On 05/21/2018 02:30 PM, Steve Grubb wrote:
> > > Hello Stefan,
> > >
> > > On Monday, May 21, 2018 1:53:04 PM EDT Stefan Berger wrote:
> > > > On 05/21/2018 12:58 PM, Steve Grubb wrote:
> > > > > 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.
> > > >
> > > > It's calling audit_log_string() in both cases:
> > > >
> > > > https://elixir.bootlin.com/linux/latest/source/security/integrity/int
> > > > egrity _audit.c#L48
> > >
> > > I see. Looking things over, I see that it seems like it should do the
> > > right thing. But the original purpose for this function is here:
> > >
> > > https://elixir.bootlin.com/linux/latest/source/kernel/audit.c#L1944
> > >
> > > This is where it is logging an untrusted string and has to decide to
> > > encode it or just place it in quotes. If it has quotes, that means
> > > it's an untrusted string but has no control characters in it. I think
> > > you want to use audit_log_format() for any string that is trustworthy.
> >
> > Replacing all occurrences (in IMA) of audit_log_string() with
> > audit_log_format().
> >
> > > As an aside, I wonder why audit_log_string() is in the API when it is a
> > > helper to audit_log_untrustedstring() ? Without understanding the
> > > rules of untrusted strings, it can't be used correctly without
> > > re-inventing audit_log_untrustedstring() by hand.
> > >
> > > > > > 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
> > > >
> > > > We will call into audit_log_task, which will put the parameters into
> > > > correct order:
> > > >
> > > > auid uid gid ses subj pid comm exe
> > >
> > > I'm telling you what the correct order is. :-) A long time ago, the
> > > IMA
> > :
> > :-) Thanks. Was getting confused.
> > :
> > > system had audit events with the order I'm mentioning. For example,
> > > here's
> > > one from a log I collected back in 2013:
> > >
> > > type=INTEGRITY_PCR msg=audit(1327409021.813:21): pid=1 uid=0
> > > auid=4294967295 ses=4294967295 subj=kernel op="add_template_measure"
> > > cause="hash_added" comm="init" name="01parse-kernel.sh" dev=rootfs
> > > ino=5413 res=0
> > >
> > > it was missing "tty" and "exe", but the order is as I mentioned. The
> > > expectation is that INTEGRITY events maintain this established order
> > > across all events.
> >
> > I am *appending* exe= and tty= now:
> >
> > type=INTEGRITY_PCR msg=audit(1526939047.809:305): pid=1609 uid=0 auid=0
> > ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > op="invalid_pcr" cause="open_writers" comm="ssh"
> > name="/var/lib/sss/mc/passwd" dev="dm-0" ino=1962679 res=1
> > exe="/usr/bin/ssh" tty=tty2
>
> This isn't necessary since they already covered in the already
> connected SYSCALL record which duplicates even more information than is
> already.
My logs don't show any syscall record being attached. Nor should it. This is
a simple event that should stand on its own.
-Steve
next prev parent reply other threads:[~2018-05-22 14:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1520257393.10396.291.camel@linux.vnet.ibm.com>
[not found] ` <1520257393.10396.291.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-03-05 13:50 ` [PATCH] audit: add containerid support for IMA-audit Richard Guy Briggs
[not found] ` <20180305135008.po6lheqnmkqqo6q4@madcap2.tricolour.ca>
[not found] ` <20180305135008.po6lheqnmkqqo6q4-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-03-05 14:24 ` Mimi Zohar
[not found] ` <1520259854.10396.313.camel@linux.vnet.ibm.com>
[not found] ` <1520259854.10396.313.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-03-08 11:21 ` Richard Guy Briggs
[not found] ` <20180308112104.z67wohdvjqemy7wy@madcap2.tricolour.ca>
[not found] ` <1520532165.3605.51.camel@linux.vnet.ibm.com>
[not found] ` <1520532165.3605.51.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-03-13 5:53 ` Richard Guy Briggs
[not found] ` <20180308112104.z67wohdvjqemy7wy-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-03-08 18:02 ` Mimi Zohar
2018-05-17 14:18 ` Stefan Berger
[not found] ` <efb6c164-febe-67bb-43a9-795476c4902f@linux.vnet.ibm.com>
[not found] ` <20180517213001.62caslkjwv575xgl@madcap2.tricolour.ca>
[not found] ` <20180517213001.62caslkjwv575xgl-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-05-18 11:49 ` Stefan Berger
[not found] ` <86df5c2c-9db3-21b9-b91b-30a4f53f9504@linux.vnet.ibm.com>
[not found] ` <1526647996.3632.164.camel@linux.vnet.ibm.com>
[not found] ` <1526647996.3632.164.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 13:54 ` Stefan Berger
2018-05-18 15:51 ` Richard Guy Briggs
[not found] ` <ef567d60-42f7-0a87-8597-1ef381e15be0@linux.vnet.ibm.com>
[not found] ` <ef567d60-42f7-0a87-8597-1ef381e15be0-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 14:39 ` Mimi Zohar
[not found] ` <1526654395.3632.196.camel@linux.vnet.ibm.com>
[not found] ` <1526654395.3632.196.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 14:52 ` Stefan Berger
2018-05-18 15:56 ` Richard Guy Briggs
[not found] ` <1347e0c5-40c9-34a4-9c54-60bd2917b2d7@linux.vnet.ibm.com>
[not found] ` <1347e0c5-40c9-34a4-9c54-60bd2917b2d7-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 16:00 ` Richard Guy Briggs
[not found] ` <20180518155659.porewd6moctumkys@madcap2.tricolour.ca>
[not found] ` <20180518155659.porewd6moctumkys-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-05-18 16:34 ` Mimi Zohar
[not found] ` <1526661264.3404.55.camel@linux.vnet.ibm.com>
[not found] ` <1526661264.3404.55.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 16:50 ` Richard Guy Briggs
2018-05-21 17:21 ` Steve Grubb
[not found] ` <5705556.pzqfGOkdjC@x2>
2018-05-21 18:04 ` Stefan Berger
[not found] ` <7abd3460-0797-f003-12c7-7329beb0835b@linux.vnet.ibm.com>
[not found] ` <7abd3460-0797-f003-12c7-7329beb0835b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-21 18:40 ` Steve Grubb
[not found] ` <86df5c2c-9db3-21b9-b91b-30a4f53f9504-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 12:53 ` Mimi Zohar
2018-05-18 15:45 ` Richard Guy Briggs
[not found] ` <20180518154553.dy53m3os7aql3urd-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-05-18 16:49 ` Stefan Berger
[not found] ` <7fdca0e0-19d5-1f08-8aa2-f295ad3a86de@linux.vnet.ibm.com>
[not found] ` <7fdca0e0-19d5-1f08-8aa2-f295ad3a86de-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-18 17:01 ` Richard Guy Briggs
[not found] ` <efb6c164-febe-67bb-43a9-795476c4902f-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-17 21:30 ` Richard Guy Briggs
2018-05-21 16:58 ` Steve Grubb
[not found] ` <2397631.78oLu0QVqb@x2>
2018-05-21 17:53 ` Stefan Berger
[not found] ` <21646a72-e782-e33a-9e75-5cc98b241f36@linux.vnet.ibm.com>
[not found] ` <21646a72-e782-e33a-9e75-5cc98b241f36-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-21 18:30 ` Steve Grubb
2018-05-21 21:57 ` Stefan Berger
[not found] ` <e140278a-1494-ec74-f8bb-7fbac676306e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-05-22 13:43 ` Richard Guy Briggs
2018-05-22 14:09 ` Steve Grubb
[not found] ` <20180522134346.b3bm7ndfjjchju3b@madcap2.tricolour.ca>
[not found] ` <20180522134346.b3bm7ndfjjchju3b-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
2018-05-22 14:12 ` Steve Grubb [this message]
2018-03-05 13:43 Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='7716958.jNg3Sb0t5f__32342.1664107174$1526998235$gmane$org@x2' \
--to=sgrubb-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-integrity-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org \
--cc=rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).