Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-10-22 21:21, Paul Moore wrote:
On Wed, Oct 21, 2020 at 12:39 PM Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> Here is an exmple I was able to generate after updating the testsuite
> script to include a signalling example of a nested audit container
> identifier:
>
> ----
> type=PROCTITLE msg=audit(2020-10-21 10:31:16.655:6731) : proctitle=/usr/bin/perl -w
containerid/test
> type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) :
contid=7129731255799087104^3333941723245477888
> type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115583 oauid=root
ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl
> type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) :
contid=3333941723245477888
> type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115580 oauid=root
ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl
> type=CONTAINER_ID msg=audit(2020-10-21 10:31:16.655:6731) :
contid=8098399240850112512^3333941723245477888
> type=OBJ_PID msg=audit(2020-10-21 10:31:16.655:6731) : opid=115582 oauid=root
ouid=root oses=1 obj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 ocomm=perl
> type=SYSCALL msg=audit(2020-10-21 10:31:16.655:6731) : arch=x86_64 syscall=kill
success=yes exit=0 a0=0xfffe3c84 a1=SIGTERM a2=0x4d524554 a3=0x0 items=0 ppid=115564
pid=115567 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root
fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
key=testsuite-1603290671-AcLtUulY
> ----
>
> There are three CONTAINER_ID records which need some way of associating with OBJ_PID
records. An additional CONTAINER_ID record would be present if the killing process itself
had an audit container identifier. I think the most obvious way to connect them is with a
pid= field in the CONTAINER_ID record.
Using a "pid=" field as a way to link CONTAINER_ID records to other
records raises a few questions. What happens if/when we need to
represent those PIDs in the context of a namespace? Are we ever going
to need to link to records which don't have a "pid=" field? I haven't
done the homework to know if either of these are a concern right now,
but I worry that this might become a problem in the future.
Good point about PID namespaces in the future but those accompanying
records will already have to be conditioned for the PID namespace
context that is requesting it, so I don't see this as a showstopper.
I've forgotten about an important one we already hit, which is a network
event that only has a NETFILTER_PKT record, but in that case, there is
no ambiguity since there are no other records associated with that
event. So the second is already an issue now. Using
task_tgid_nr(current), in the contid testsuite script network event it
attributed it to ping which caused the event, but we cannot use this
since it wasn't triggered by a syscall and doesn't accurately reflect
the kernel thread that received it. It could just be set to zero for
network events.
The idea of using something like "item=" is interesting.
As you
mention, the "item=" field does present some overlap problems with the
PATH record, but perhaps we can do something similar. What if we
added a "record=" (or similar, I'm not worried about names at this
point) to each record, reset to 0/1 at the start of each event, and
when we needed to link records somehow we could add a "related=1,..,N"
field. This would potentially be useful beyond just the audit
container ID work.
Does it make any sense to use the same keyword in each type of record
such as record/records as in PATH/SYSCALL: item/items ?
(I prefer 0-indexed like item=...)
paul moore
- RGB
--
Richard Guy Briggs <rgb(a)redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635