On 2018-07-22 16:55, Richard Guy Briggs wrote:

On 2018-07-22 09:32, Steve Grubb wrote:

quoted

On Saturday, July 21, 2018 4:29:30 PM EDT Richard Guy Briggs wrote:

quoted

quoted

quoted

+ * audit_log_contid - report container info
+ * @tsk: task to be recorded
+ * @context: task or local context for record
+ * @op: contid string description
+ */
+int audit_log_contid(struct task_struct *tsk,
+                            struct audit_context *context, char *op)
+{
+       struct audit_buffer *ab;
+
+       if (!audit_contid_set(tsk))
+               return 0;
+       /* Generate AUDIT_CONTAINER record with container ID */
+       ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER);
+       if (!ab)
+               return -ENOMEM;
+       audit_log_format(ab, "op=%s contid=%llu",
+                        op, audit_get_contid(tsk));

Can you explain your reason for including an "op" field in this record
type?  I've been looking at the rest of the patches in this patchset
and it seems to be used more as an indicator of the record's
generating context rather than any sort of audit container ID
operation.

"action" might work, but that's netfilter and numeric... "kind"?
Nothing else really seems to fit from a field name, type or lack of
searchability perspective.

Steve, do you have an opinion?

We only have 1 sample event where we have op=task. What are the other 
possible values?

For the AUDIT_CONTAINER record we have op= "task", "target" (from the
ptrace and signals patch), "tty".

Sorry, pressed "send" too quickly.  Also "aux0x%x" (also from the
ptrace/signals patch), "net%u" (from the AUDIT_NETFILTER_PKT patch).

For the AUDIT_CONTAINER_ID record we have "op=set".

quoted

-Steve

- RGB

- 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