From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CFB1BC004D3 for ; Wed, 24 Oct 2018 15:15:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92CB3207DD for ; Wed, 24 Oct 2018 15:15:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 92CB3207DD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726997AbeJXXnv (ORCPT ); Wed, 24 Oct 2018 19:43:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46416 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbeJXXnv (ORCPT ); Wed, 24 Oct 2018 19:43:51 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B4CE37655D; Wed, 24 Oct 2018 15:15:20 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-24.phx2.redhat.com [10.3.112.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AEEC810694C6; Wed, 24 Oct 2018 15:14:42 +0000 (UTC) Date: Wed, 24 Oct 2018 11:14:39 -0400 From: Richard Guy Briggs To: Paul Moore Cc: containers@lists.linux-foundation.org, linux-api@vger.kernel.org, linux-audit@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, ebiederm@xmission.com, luto@kernel.org, carlos@redhat.com, dhowells@redhat.com, viro@zeniv.linux.org.uk, simo@redhat.com, Eric Paris , Serge Hallyn Subject: Re: [PATCH ghak90 (was ghak32) V4 03/10] audit: log container info of syscalls Message-ID: <20181024151439.lavhanabsyxdrdvo@madcap2.tricolour.ca> References: <34017c395d03a213d6b0d49b9964429bd32b283d.1533065887.git.rgb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 24 Oct 2018 15:15:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-10-19 19:16, Paul Moore wrote: > On Sun, Aug 5, 2018 at 4:32 AM Richard Guy Briggs wrote: > > Create a new audit record AUDIT_CONTAINER to document the audit > > container identifier of a process if it is present. > > > > Called from audit_log_exit(), syscalls are covered. > > > > A sample raw event: > > type=SYSCALL msg=audit(1519924845.499:257): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c 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=0000000000000000 cap_fi=0000000000000000 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=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 > > type=PROCTITLE msg=audit(1519924845.499:257): proctitle=62617368002D6300736C65657020313B206563686F2074657374203E202F746D702F746D70636F6E7461696E65726964 > > type=CONTAINER msg=audit(1519924845.499:257): op=task contid=123458 > > > > See: https://github.com/linux-audit/audit-kernel/issues/90 > > See: https://github.com/linux-audit/audit-userspace/issues/51 > > See: https://github.com/linux-audit/audit-testsuite/issues/64 > > See: 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 > > --- > > include/linux/audit.h | 7 +++++++ > > include/uapi/linux/audit.h | 1 + > > kernel/audit.c | 24 ++++++++++++++++++++++++ > > kernel/auditsc.c | 3 +++ > > 4 files changed, 35 insertions(+) > > ... > > > @@ -2045,6 +2045,30 @@ void audit_log_session_info(struct audit_buffer *ab) > > audit_log_format(ab, " auid=%u ses=%u", auid, sessionid); > > } > > > > +/* > > + * 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)); > > + audit_log_end(ab); > > + return 0; > > +} > > +EXPORT_SYMBOL(audit_log_contid); > > As discussed in the previous iteration of the patch, I prefer > AUDIT_CONTAINER_ID here over AUDIT_CONTAINER. If you feel strongly > about keeping it as-is with AUDIT_CONTAINER I suppose I could live > with that, but it is isn't my first choice. I don't have a strong opinion on this one, mildly preferring the shorter one only because it is shorter. Steve? Can you comment on this one way or the other? > 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. > 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