Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On Fri, Oct 23, 2020 at 4:40 PM Richard Guy Briggs wrote: > On 2020-10-22 21:21, Paul Moore wrote: > > On Wed, Oct 21, 2020 at 12:39 PM Richard Guy Briggs 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^941723245477888 > > > 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=941723245477888 > > > 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^941723245477888 > > > 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. Possibly, it just gets very messy. Doubly so when you start looking at potentially adjusting for multiple audit daemons. Thankfully it doesn't look like using the PID is a good idea for other reasons. > 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. Possibly. It just seems like too much hackery to start; that's the stuff you do once it has been in a kernel release for years and need to find a workaround that doesn't break everything. I think we should aim a bit higher right now. > > 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 ? That was mentioned above, if you can assure yourself and the rest of us that it can be safely reused I think that might be okay, but I'm not convinced that is safe at the moment. Although I will admit those are fears are not based on an exhaustive search through the code (or a determined "think"). > (I prefer 0-indexed like item=...) I have no preference on where we start the index, but it makes sense to keep the same index starting point as the PATH records. -- paul moore www.paul-moore.com
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 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^941723245477888 > > 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=941723245477888 > > 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^941723245477888 > > 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 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
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On Wed, Oct 21, 2020 at 12:39 PM Richard Guy Briggs 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^941723245477888 > 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=941723245477888 > 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^941723245477888 > 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. 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. -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-10-21 12:49, Steve Grubb wrote: > On Wednesday, October 21, 2020 12:39:26 PM EDT Richard Guy Briggs wrote: > > > I think I have a way to generate a signal to multiple targets in one > > > syscall... The added challenge is to also give those targets different > > > audit container identifiers. > > > > 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^941723245477888 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=941723245477888 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^941723245477888 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. > > pid is the process sending the signal, opid is the process receiving the > signal. I think you mean opid? If the process sending the signal (it has a pid= field) has an audit container identifier, it will generate a CONTAINER_ID record. Each process being signalled (each has an opid= field) that has an audit container identifier will also generate a CONTAINER_ID record. The former will be much more common. Which do we use in the CONTAINER_ID record? Having swinging fields, pid vs opid does not seem like a reasonable solution. Do we go back to "ref=pid=..." vs "ref=opid=..."? > -Steve - RGB -- Richard Guy Briggs 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
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On Wednesday, October 21, 2020 12:39:26 PM EDT Richard Guy Briggs wrote: > > I think I have a way to generate a signal to multiple targets in one > > syscall... The added challenge is to also give those targets different > > audit container identifiers. > > 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^941723245477888 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=941723245477888 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^941723245477888 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. pid is the process sending the signal, opid is the process receiving the signal. I think you mean opid? -Steve
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-10-02 15:52, Richard Guy Briggs wrote:
> On 2020-08-21 15:15, Paul Moore wrote:
> > On Wed, Jul 29, 2020 at 3:41 PM Richard Guy Briggs wrote:
> > > On 2020-07-05 11:10, Paul Moore wrote:
> > > > On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs
> > > > wrote:
> >
> > ...
> >
> > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > > index f03d3eb0752c..9e79645e5c0e 100644
> > > > > --- a/kernel/auditsc.c
> > > > > +++ b/kernel/auditsc.c
> > > > > @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> > > > > struct audit_buffer *ab;
> > > > > struct audit_aux_data *aux;
> > > > > struct audit_names *n;
> > > > > + struct audit_contobj *cont;
> > > > >
> > > > > context->personality = current->personality;
> > > > >
> > > > > @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> > > > > for (aux = context->aux_pids; aux; aux = aux->next) {
> > > > > struct audit_aux_data_pids *axs = (void *)aux;
> > > > >
> > > > > - for (i = 0; i < axs->pid_count; i++)
> > > > > + for (i = 0; i < axs->pid_count; i++) {
> > > > > if (audit_log_pid_context(context,
> > > > > axs->target_pid[i],
> > > > > axs->target_auid[i],
> > > > > axs->target_uid[i],
> > > > > @@ -1549,14 +1558,20 @@ static void audit_log_exit(void)
> > > > > axs->target_sid[i],
> > > > >
> > > > > axs->target_comm[i]))
> > > > > call_panic = 1;
> > > > > + audit_log_container_id(context,
> > > > > axs->target_cid[i]);
> > > > > + }
> > > >
> > > > It might be nice to see an audit event example including the
> > > > ptrace/signal information. I'm concerned there may be some confusion
> > > > about associating the different audit container IDs with the correct
> > > > information in the event.
> > >
> > > This is the subject of ghat81, which is a test for ptrace and signal
> > > records.
> > >
> > > This was the reason I had advocated for an op= field since there is a
> > > possibility of multiple contid records per event.
> >
> > I think an "op=" field is the wrong way to link audit container ID to
> > a particular record. It may be convenient, but I fear that it would
> > be overloading the field too much.
>
> Ok, after looking at the field dictionary how about item, rel, ref or rec?
> Item perhaps could be added to the OBJ_PID records, but that might be
> overloading a field that is already used in PATH records. "rel" for
> relates-to, "ref" for reference to, "rec" for record... Perhaps pid=
> would be enough to tie this record to the OBJ_PID record or the SYSCALL
> record, but in the case of network events, the pid may refer to a kernel
> thread.
>
> > Like I said above, I think it would be good to see an audit event
> > example including the ptrace/signal information. This way we can talk
> > about it on-list and hash out the various solutions if it proves to be
> > a problem.
>
> See the list posting from 2020-09-29 "auditing signals" pointing to
> ghat81 test case about testing ptrace and signals from 18 months ago.
>
> I think I have a way to generate a signal to multiple targets in one
> syscall... The added challenge is to also give those targets different
> audit container identifiers.
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^941723245477888
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=941723245477888
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^941723245477888
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
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-08-21 15:15, Paul Moore wrote:
> On Wed, Jul 29, 2020 at 3:41 PM Richard Guy Briggs wrote:
> > On 2020-07-05 11:10, Paul Moore wrote:
> > > On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs
> > > wrote:
>
> ...
>
> > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > > index f03d3eb0752c..9e79645e5c0e 100644
> > > > --- a/kernel/auditsc.c
> > > > +++ b/kernel/auditsc.c
> > > > @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> > > > struct audit_buffer *ab;
> > > > struct audit_aux_data *aux;
> > > > struct audit_names *n;
> > > > + struct audit_contobj *cont;
> > > >
> > > > context->personality = current->personality;
> > > >
> > > > @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> > > > for (aux = context->aux_pids; aux; aux = aux->next) {
> > > > struct audit_aux_data_pids *axs = (void *)aux;
> > > >
> > > > - for (i = 0; i < axs->pid_count; i++)
> > > > + for (i = 0; i < axs->pid_count; i++) {
> > > > if (audit_log_pid_context(context,
> > > > axs->target_pid[i],
> > > > axs->target_auid[i],
> > > > axs->target_uid[i],
> > > > @@ -1549,14 +1558,20 @@ static void audit_log_exit(void)
> > > > axs->target_sid[i],
> > > > axs->target_comm[i]))
> > > > call_panic = 1;
> > > > + audit_log_container_id(context,
> > > > axs->target_cid[i]);
> > > > + }
> > >
> > > It might be nice to see an audit event example including the
> > > ptrace/signal information. I'm concerned there may be some confusion
> > > about associating the different audit container IDs with the correct
> > > information in the event.
> >
> > This is the subject of ghat81, which is a test for ptrace and signal
> > records.
> >
> > This was the reason I had advocated for an op= field since there is a
> > possibility of multiple contid records per event.
>
> I think an "op=" field is the wrong way to link audit container ID to
> a particular record. It may be convenient, but I fear that it would
> be overloading the field too much.
Ok, after looking at the field dictionary how about item, rel, ref or rec?
Item perhaps could be added to the OBJ_PID records, but that might be
overloading a field that is already used in PATH records. "rel" for
relates-to, "ref" for reference to, "rec" for record... Perhaps pid=
would be enough to tie this record to the OBJ_PID record or the SYSCALL
record, but in the case of network events, the pid may refer to a kernel
thread.
> Like I said above, I think it would be good to see an audit event
> example including the ptrace/signal information. This way we can talk
> about it on-list and hash out the various solutions if it proves to be
> a problem.
See the list posting from 2020-09-29 "auditing signals" pointing to
ghat81 test case about testing ptrace and signals from 18 months ago.
I think I have a way to generate a signal to multiple targets in one
syscall... The added challenge is to also give those targets different
audit container identifiers.
> > > > @@ -1575,6 +1590,14 @@ static void audit_log_exit(void)
> > > >
> > > > audit_log_proctitle();
> > > >
> > > > + rcu_read_lock();
> > > > + cont = _audit_contobj_get(current);
> > > > + rcu_read_unlock();
> > > > + audit_log_container_id(context, cont);
> > > > + rcu_read_lock();
> > > > + _audit_contobj_put(cont);
> > > > + rcu_read_unlock();
> > >
> > > Do we need to grab an additional reference for the audit container
> > > object here? We don't create any additional references here that
> > > persist beyond the lifetime of this function, right?
> >
> > Why do we need another reference? There's one for each pointer pointing
> > to it and so far we have just one from this task. Or are you thinking
> > of the contid hash list, which is only added to when a task points to it
> > and gets removed from that list when the last task stops pointing to it.
> > Later that gets more complicated with network namespaces and nested
> > container objects. For now we just needed it while generating the
> > record, then it gets freed.
>
> I don't think we need to grab an additional reference here, that is
> why I asked the question. The code above grabs a reference for the
> audit container ID object associated with the current task and then
> drops it before returning; if the current task, and it's associated
> audit container ID object, disappears in the middle of the function
> we've got much bigger worries :)
I misunderstood your question previously thinking you wanted yet another
reference taken in this case, when in fact it was the opposite and you
thought the one taken here was
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On Wed, Jul 29, 2020 at 3:41 PM Richard Guy Briggs wrote:
> On 2020-07-05 11:10, Paul Moore wrote:
> > On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs wrote:
...
> > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > > index f03d3eb0752c..9e79645e5c0e 100644
> > > --- a/kernel/auditsc.c
> > > +++ b/kernel/auditsc.c
> > > @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> > > struct audit_buffer *ab;
> > > struct audit_aux_data *aux;
> > > struct audit_names *n;
> > > + struct audit_contobj *cont;
> > >
> > > context->personality = current->personality;
> > >
> > > @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> > > for (aux = context->aux_pids; aux; aux = aux->next) {
> > > struct audit_aux_data_pids *axs = (void *)aux;
> > >
> > > - for (i = 0; i < axs->pid_count; i++)
> > > + for (i = 0; i < axs->pid_count; i++) {
> > > if (audit_log_pid_context(context,
> > > axs->target_pid[i],
> > > axs->target_auid[i],
> > > axs->target_uid[i],
> > > @@ -1549,14 +1558,20 @@ static void audit_log_exit(void)
> > > axs->target_sid[i],
> > > axs->target_comm[i]))
> > > call_panic = 1;
> > > + audit_log_container_id(context,
> > > axs->target_cid[i]);
> > > + }
> >
> > It might be nice to see an audit event example including the
> > ptrace/signal information. I'm concerned there may be some confusion
> > about associating the different audit container IDs with the correct
> > information in the event.
>
> This is the subject of ghat81, which is a test for ptrace and signal
> records.
>
> This was the reason I had advocated for an op= field since there is a
> possibility of multiple contid records per event.
I think an "op=" field is the wrong way to link audit container ID to
a particular record. It may be convenient, but I fear that it would
be overloading the field too much.
Like I said above, I think it would be good to see an audit event
example including the ptrace/signal information. This way we can talk
about it on-list and hash out the various solutions if it proves to be
a problem.
> > > @@ -1575,6 +1590,14 @@ static void audit_log_exit(void)
> > >
> > > audit_log_proctitle();
> > >
> > > + rcu_read_lock();
> > > + cont = _audit_contobj_get(current);
> > > + rcu_read_unlock();
> > > + audit_log_container_id(context, cont);
> > > + rcu_read_lock();
> > > + _audit_contobj_put(cont);
> > > + rcu_read_unlock();
> >
> > Do we need to grab an additional reference for the audit container
> > object here? We don't create any additional references here that
> > persist beyond the lifetime of this function, right?
>
> Why do we need another reference? There's one for each pointer pointing
> to it and so far we have just one from this task. Or are you thinking
> of the contid hash list, which is only added to when a task points to it
> and gets removed from that list when the last task stops pointing to it.
> Later that gets more complicated with network namespaces and nested
> container objects. For now we just needed it while generating the
> record, then it gets freed.
I don't think we need to grab an additional reference here, that is
why I asked the question. The code above grabs a reference for the
audit container ID object associated with the current task and then
drops it before returning; if the current task, and it's associated
audit container ID object, disappears in the middle of the function
we've got much bigger worries :)
--
paul moore
www.paul-moore.com
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On 2020-07-05 11:10, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs wrote:
> >
> > Create a new audit record AUDIT_CONTAINER_ID to document the audit
> > container identifier of a process if it is present.
> >
> > Called from audit_log_exit(), syscalls are covered.
> >
> > Include target_cid references from ptrace and signal.
> >
> > A sample raw event:
> > type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> > success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2
> > ppid=606 pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > fsgid=0 tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > key="tmpcontainerid"
> > type=CWD msg=audit(1519924845.499:257): cwd="/root"
> > type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863
> > dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00
> > obj=system_u:object_r:tmp_t:s0 nametype= PARENT cap_fp=0 cap_fi=0 cap_fe=0
> > cap_fver=0
> > type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid"
> > inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00
> > obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0 cap_fi=0
> > cap_fe=0 cap_fver=0
> > type=PROCTITLE msg=audit(1519924845.499:257):
> > proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> > type=CONTAINER_ID msg=audit(1519924845.499:257): contid=123458
> >
> > Please see the github audit kernel issue for the main feature:
> > https://github.com/linux-audit/audit-kernel/issues/90
> > Please see the github audit userspace issue for supporting additions:
> > https://github.com/linux-audit/audit-userspace/issues/51
> > Please see the github audit testsuiite issue for the test case:
> > https://github.com/linux-audit/audit-testsuite/issues/64
> > Please see the github audit wiki for the feature overview:
> > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> > Signed-off-by: Richard Guy Briggs
> > Acked-by: Serge Hallyn
> > Acked-by: Steve Grubb
> > Acked-by: Neil Horman
> > Reviewed-by: Ondrej Mosnacek
> > ---
> > include/linux/audit.h | 7 +++
> > include/uapi/linux/audit.h | 1 +
> > kernel/audit.c | 25 +++--
> > kernel/audit.h | 4
> > kernel/auditsc.c | 45
> > +++--
> > 5 files changed, 74 insertions(+), 8 deletions(-)
>
> ...
>
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 9e0b38ce1ead..a09f8f661234 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -2211,6 +2211,27 @@ void audit_log_session_info(struct audit_buffer *ab)
> > audit_log_format(ab, "auid=%u ses=%u", auid, sessionid);
> > }
> >
> > +/*
> > + * audit_log_container_id - report container info
> > + * @context: task or local context for record
> > + * @cont: container object to report
> > + */
> > +void audit_log_container_id(struct audit_context *context,
> > + struct audit_contobj *cont)
> > +{
> > + struct audit_buffer *ab;
> > +
> > + if (!cont)
> > + return;
> > + /* Generate AUDIT_CONTAINER_ID record with container ID */
> > + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER_ID);
> > + if (!ab)
> > + return;
> > + audit_log_format(ab, "contid=%llu", contid);
>
> Did this patch compile? Where is "contid" coming from? I'm guessing
> you mean to get it from "cont", but that isn't what appears to be
> happening; likely a casualty of the object vs token discussion we had
> during the last review cycle.
Yes, it was supposed to be cont->id.
> I'm assuming this code gets modified later in this patchset and you
> only compiled tested the patchset as a whole. Please make sure the
> patchset compiles at each patch along the way to applying them all;
> this helps ensure that git bisect remains useful and it fits better
> with the general idea that individual patches must have merit on their
> own.
Yes, agreed.
> ... and yes, I do check for this when merging patchsets, it isn't just
> a visual inspection, I compile test each patch.
>
> If nothing else, at least this answers the question of if it is worth
> respinning or not (this alone requires a respin).
>
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index f03d3eb0752c..9e79645e5c0e 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> > struct audit_buffer *ab;
> > struct audit_aux_data *aux;
> > struct audit_names *n;
> > + struct audit_contobj *cont;
> >
> > context->personality = current->personality;
> >
> > @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> > for (aux = context->aux_pids; aux; aux = aux->next) {
> > struct
Re: [PATCH ghak90 V9 05/13] audit: log container info of syscalls
On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs wrote:
>
> Create a new audit record AUDIT_CONTAINER_ID to document the audit
> container identifier of a process if it is present.
>
> Called from audit_log_exit(), syscalls are covered.
>
> Include target_cid references from ptrace and signal.
>
> A sample raw event:
> type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
> success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2 ppid=606
> pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=pts0 ses=3 comm="bash" exe="/usr/bin/bash"
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> key="tmpcontainerid"
> type=CWD msg=audit(1519924845.499:257): cwd="/root"
> type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863
> dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0
> nametype= PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
> type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid"
> inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00
> obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0 cap_fi=0
> cap_fe=0 cap_fver=0
> type=PROCTITLE msg=audit(1519924845.499:257):
> proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
> type=CONTAINER_ID msg=audit(1519924845.499:257): contid=123458
>
> Please see the github audit kernel issue for the main feature:
> https://github.com/linux-audit/audit-kernel/issues/90
> Please see the github audit userspace issue for supporting additions:
> https://github.com/linux-audit/audit-userspace/issues/51
> Please see the github audit testsuiite issue for the test case:
> https://github.com/linux-audit/audit-testsuite/issues/64
> Please see the github audit wiki for the feature overview:
> https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
> Signed-off-by: Richard Guy Briggs
> Acked-by: Serge Hallyn
> Acked-by: Steve Grubb
> Acked-by: Neil Horman
> Reviewed-by: Ondrej Mosnacek
> ---
> include/linux/audit.h | 7 +++
> include/uapi/linux/audit.h | 1 +
> kernel/audit.c | 25 +++--
> kernel/audit.h | 4
> kernel/auditsc.c | 45 +++--
> 5 files changed, 74 insertions(+), 8 deletions(-)
...
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 9e0b38ce1ead..a09f8f661234 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -2211,6 +2211,27 @@ void audit_log_session_info(struct audit_buffer *ab)
> audit_log_format(ab, "auid=%u ses=%u", auid, sessionid);
> }
>
> +/*
> + * audit_log_container_id - report container info
> + * @context: task or local context for record
> + * @cont: container object to report
> + */
> +void audit_log_container_id(struct audit_context *context,
> + struct audit_contobj *cont)
> +{
> + struct audit_buffer *ab;
> +
> + if (!cont)
> + return;
> + /* Generate AUDIT_CONTAINER_ID record with container ID */
> + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER_ID);
> + if (!ab)
> + return;
> + audit_log_format(ab, "contid=%llu", contid);
Did this patch compile? Where is "contid" coming from? I'm guessing
you mean to get it from "cont", but that isn't what appears to be
happening; likely a casualty of the object vs token discussion we had
during the last review cycle.
I'm assuming this code gets modified later in this patchset and you
only compiled tested the patchset as a whole. Please make sure the
patchset compiles at each patch along the way to applying them all;
this helps ensure that git bisect remains useful and it fits better
with the general idea that individual patches must have merit on their
own.
... and yes, I do check for this when merging patchsets, it isn't just
a visual inspection, I compile test each patch.
If nothing else, at least this answers the question of if it is worth
respinning or not (this alone requires a respin).
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index f03d3eb0752c..9e79645e5c0e 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1458,6 +1466,7 @@ static void audit_log_exit(void)
> struct audit_buffer *ab;
> struct audit_aux_data *aux;
> struct audit_names *n;
> + struct audit_contobj *cont;
>
> context->personality = current->personality;
>
> @@ -1541,7 +1550,7 @@ static void audit_log_exit(void)
> for (aux = context->aux_pids; aux; aux = aux->next) {
> struct audit_aux_data_pids *axs = (void *)aux;
>
> - for (i = 0; i < axs->pid_count; i++)
> + for (i = 0; i < axs->pid_count; i++) {
> if (audit_log_pid_context(context, axs->target_pid[i],
> axs->target_auid[i],
>
[PATCH ghak90 V9 05/13] audit: log container info of syscalls
Create a new audit record AUDIT_CONTAINER_ID to document the audit
container identifier of a process if it is present.
Called from audit_log_exit(), syscalls are covered.
Include target_cid references from ptrace and signal.
A sample raw event:
type=SYSCALL msg=audit(1519924845.499:257): arch=c03e syscall=257
success=yes exit=3 a0=ff9c a1=56374e1cef30 a2=241 a3=1b6 items=2 ppid=606
pid=635 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
ses=3 comm="bash" exe="/usr/bin/bash"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="tmpcontainerid"
type=CWD msg=audit(1519924845.499:257): cwd="/root"
type=PATH msg=audit(1519924845.499:257): item=0 name="/tmp/" inode=13863
dev=00:27 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0
nametype= PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0
type=PATH msg=audit(1519924845.499:257): item=1 name="/tmp/tmpcontainerid"
inode=17729 dev=00:27 mode=0100644 ouid=0 ogid=0 rdev=00:00
obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE cap_fp=0 cap_fi=0
cap_fe=0 cap_fver=0
type=PROCTITLE msg=audit(1519924845.499:257):
proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964
type=CONTAINER_ID msg=audit(1519924845.499:257): contid=123458
Please see the github audit kernel issue for the main feature:
https://github.com/linux-audit/audit-kernel/issues/90
Please see the github audit userspace issue for supporting additions:
https://github.com/linux-audit/audit-userspace/issues/51
Please see the github audit testsuiite issue for the test case:
https://github.com/linux-audit/audit-testsuite/issues/64
Please see the github audit wiki for the feature overview:
https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Container-ID
Signed-off-by: Richard Guy Briggs
Acked-by: Serge Hallyn
Acked-by: Steve Grubb
Acked-by: Neil Horman
Reviewed-by: Ondrej Mosnacek
---
include/linux/audit.h | 7 +++
include/uapi/linux/audit.h | 1 +
kernel/audit.c | 25 +++--
kernel/audit.h | 4
kernel/auditsc.c | 45 +++--
5 files changed, 74 insertions(+), 8 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 2800d4f1a2a8..5eeba0efffc2 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -222,6 +222,9 @@ static inline u64 audit_get_contid(struct task_struct *tsk)
return tsk->audit->cont->id;
}
+extern void audit_log_container_id(struct audit_context *context,
+ struct audit_contobj *cont);
+
extern u32 audit_enabled;
extern int audit_signal_info(int sig, struct task_struct *t);
@@ -291,6 +294,10 @@ static inline u64 audit_get_contid(struct task_struct *tsk)
return AUDIT_CID_UNSET;
}
+static inline void audit_log_container_id(struct audit_context *context,
+ struct audit_contobj *cont)
+{ }
+
#define audit_enabled AUDIT_OFF
static inline int audit_signal_info(int sig, struct task_struct *t)
diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
index 859382527210..fd98460c983f 100644
--- a/include/uapi/linux/audit.h
+++ b/include/uapi/linux/audit.h
@@ -119,6 +119,7 @@
#define AUDIT_TIME_ADJNTPVAL 1333/* NTP value adjustment */
#define AUDIT_BPF 1334/* BPF subsystem */
#define AUDIT_EVENT_LISTENER 1335/* Task joined multicast read socket */
+#define AUDIT_CONTAINER_ID 1336/* Container ID */
#define AUDIT_AVC 1400/* SE Linux avc denial or grant */
#define AUDIT_SELINUX_ERR 1401/* Internal SE Linux Errors */
diff --git a/kernel/audit.c b/kernel/audit.c
index 9e0b38ce1ead..a09f8f661234 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -227,7 +227,7 @@ static struct audit_contobj *_audit_contobj_hold(struct
audit_contobj *cont)
return cont;
}
-static struct audit_contobj *_audit_contobj_get(struct task_struct *tsk)
+struct audit_contobj *_audit_contobj_get(struct task_struct *tsk)
{
if (!tsk->audit)
return NULL;
@@ -235,7 +235,7 @@ static struct audit_contobj *_audit_contobj_get(struct
task_struct *tsk)
}
/* rcu_read_lock must be held by caller */
-static void _audit_contobj_put(struct audit_contobj *cont)
+void _audit_contobj_put(struct audit_contobj *cont)
{
if (!cont)
return;
@@ -2211,6 +2211,27 @@ void audit_log_session_info(struct audit_buffer *ab)
audit_log_format(ab, "auid=%u ses=%u", auid, sessionid);
}
+/*
+ * audit_log_container_id - report container info
+ * @context: task or local context for record
+ * @cont: container object to report
+ */
+void audit_log_container_id(struct audit_context *context,
+ struct audit_contobj *cont)
+{
+ struct audit_buffer *ab;
+
+ if (!cont)
+ return;
+ /* Generate
