On 2018-10-25 07:13, Paul Moore wrote:

On October 25, 2018 1:43:16 AM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2018-10-24 16:55, Paul Moore wrote:

quoted

On Wed, Oct 24, 2018 at 11:15 AM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2018-10-19 19:16, Paul Moore wrote:

quoted

On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs [off-list ref] wrote:

...

quoted

quoted

quoted

quoted

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=".  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 identifier
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.

Ok, then we should be developping a test to test ptrace and signal
auditting in general since we don't have current experience/evidence
that those even work (or rip them out if not).

paul moore

- RGB

--
Richard Guy Briggs [off-list ref]
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