From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Paul Moore To: Richard Guy Briggs CC: , , , , , , , , , , , , , Eric Paris , Serge Hallyn Date: Thu, 25 Oct 2018 07:13:07 +0100 Message-ID: <166a9dae538.280e.85c95baa4474aabc7814e68940a78392@paul-moore.com> In-Reply-To: <20181025004255.zl7p7j6gztouh2hh@madcap2.tricolour.ca> References: <34017c395d03a213d6b0d49b9964429bd32b283d.1533065887.git.rgb@redhat.com> <20181024151439.lavhanabsyxdrdvo@madcap2.tricolour.ca> <20181025004255.zl7p7j6gztouh2hh@madcap2.tricolour.ca> Subject: Re: [PATCH ghak90 (was ghak32) V4 03/10] audit: log container info of syscalls MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org List-ID: On October 25, 2018 1:43:16 AM Richard Guy Briggs wrote: > On 2018-10-24 16:55, Paul Moore wrote: >> On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs wro= te: >>> On 2018-10-19 19:16, Paul Moore wrote: >>>> On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs wro= te: > ... > >>>> However, I do care about the "op" field in this record. It just >>>> doesn't make any sense; the way you are using it it is more of a >>>> context field than an operations field, and even then why is the >>>> context important from a logging and/or security perspective? Drop it >>>> please. >>> >>> I'll rename it to whatever you like. I'd suggest "ref=3D". The reason= I >>> think it is important is there are multiple sources that aren't always >>> obvious from the other records to which it is associated. In the case >>> of ptrace and signals, there can be many target tasks listed (OBJ_PID) >>> with no other way to distinguish the matching audit container identifie= r >>> records all for one event. This is in addition to the default syscall >>> container identifier record. I'm not currently happy with the text >>> content to link the two, but that should be solvable (most obvious is >>> taret PID). Throwing away this information seems shortsighted. >> >> It would be helpful if you could generate real audit events >> demonstrating the problems you are describing, as well as a more >> standard syscall event, so we can discuss some possible solutions. > > If the auditted process is in a container and it ptraces or signals > another process in a container, there will be two AUDIT_CONTAINER > records for the same event that won't be identified as to which record > belongs to which process or other record (SYSCALL vs 1+ OBJ_PID > records). There could be many signals recorded, each with their own > OBJ_PID record. The first is stored in the audit context and additional > ones are stored in a chained struct that can accommodate 16 entries each. > > (See audit_signal_info(), __audit_ptrace().) > > (As a side note, on code inspection it appears that a signal target > would get overwritten by a ptrace action if they were to happen in that > order.) As requested above, please respond with real audit events generated by this= patchset so that we can discuss possible solutions. -- paul moore www.paul-moore.com