Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp44708ybl; Wed, 22 Jan 2020 15:46:56 -0800 (PST) X-Google-Smtp-Source: APXvYqwhnJpcKtXOy6w5NoK/tGOaLTOilG74cCNIp1w4g0RZ9bgGav0jsbomo2ZeJfSvsn5GTmCJ X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr9022932otr.82.1579736816416; Wed, 22 Jan 2020 15:46:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579736816; cv=none; d=google.com; s=arc-20160816; b=cQwNT6PLVindxzC0TTGyx8OM6cKBheoHS+/O1oj+/b0QldCiUC7+mj0Cnt0KUOpWL7 H0x4neg9ZvlSg+k4VwR3dOOjqGxwrURsKhHCq0+QeZ9dzMmnx/dydyVqernaQ7GFqLHM 32NutpjswCMGhcfTvIhvyuaXpYAsgYyqAFCCPRxpsm1WnV2Iy9v0x3Fr9CAFPbG0PfxD 0wSzfgE6n6YnrlmdycLbwpgHyywch4xU5eiuEdsHHagX12uxaLeUYS6gAuiwVSRRhYx9 064zx25v7ZnachBLHcVCatAVNYFX8wdjzSMA+o1Vc2B1YTXJLJe6XUW9wg0AXHBMar8s /8ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=yAY6s3oSzBwgsfYGnfrrOuB8hcKAqI6Ku8nNKxgPboQ=; b=iB69Nj2zhmnCscEZ4hDreGXXQL6rByTvxSW7dzQnZw57/Mmuav1JvTORvZj0QDvrwI 3ReQDZ8h6HcW7uOyl1PSjQZXO0OxluqYXn5qIO1kfTEfAi37BeyKPV7dnxnB93S8SJ5h rv3sQOxrC70HXqLI2ZwUQjSqNiXoW7O2yeqhAz61ffKa0WVHDkJtMKC9/DZ3LOJ1jbL+ Wr0QSQoD1uKLx+G+uCTyl/PZPvnEv8Gx+hpdqLvLiv25J3ta/yyb+GPxEneBoDGxictw eFxb3m0QSeajY/kUngEqcHkCDfdwZkKqrg8Bwbr1a9e37j2gH+KtmsGRzkrYqqQQEBji SAxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="MOA/PHvW"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t82si20959oif.45.2020.01.22.15.46.44; Wed, 22 Jan 2020 15:46:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="MOA/PHvW"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728205AbgAVXpJ (ORCPT + 99 others); Wed, 22 Jan 2020 18:45:09 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:31321 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725911AbgAVXpJ (ORCPT ); Wed, 22 Jan 2020 18:45:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579736707; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yAY6s3oSzBwgsfYGnfrrOuB8hcKAqI6Ku8nNKxgPboQ=; b=MOA/PHvWbkgFxxD7PtAJUkMBchVvsErZl7MWuPiitHjP+TBGxiJJ9g5SvYlTkWOUFucy+n rms5K/J6Ua4q3slMpJ3ShmOKwzssbqM+94xaZdGOLGOeXBitjJEwKYcW9mKIpJx32wPKDc mYbTi/gzThsq/DzfAYmIwo2yiVhvALU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-432-_-n7doyhOV-pNvXah0VwCg-1; Wed, 22 Jan 2020 18:45:05 -0500 X-MC-Unique: _-n7doyhOV-pNvXah0VwCg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4FF04100550E; Wed, 22 Jan 2020 23:45:04 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-12.phx2.redhat.com [10.3.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 06CD089D02; Wed, 22 Jan 2020 23:44:57 +0000 (UTC) Date: Wed, 22 Jan 2020 18:44:55 -0500 From: Richard Guy Briggs To: Steve Grubb Cc: Paul Moore , nhorman@redhat.com, LKML , Linux-Audit Mailing List , Eric Paris Subject: Re: [PATCH ghak28 V4] audit: log audit netlink multicast bind and unbind events Message-ID: <20200122234455.jg7bxrazrjpiqpe7@madcap2.tricolour.ca> References: <1907590.3WuaD5rAFU@x2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1907590.3WuaD5rAFU@x2> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-01-22 18:12, Steve Grubb wrote: > On Wednesday, January 22, 2020 5:40:10 PM EST Paul Moore wrote: > > On Fri, Jan 17, 2020 at 3:21 PM Richard Guy Briggs wrote: > > > Log information about programs connecting to and disconnecting from the > > > audit netlink multicast socket. This is needed so that during > > > investigations a security officer can tell who or what had access to the > > > audit trail. This helps to meet the FAU_SAR.2 requirement for Common > > > Criteria. Here is the systemd startup event: > > > > > > type=UNKNOWN[1335] msg=audit(2020-01-17 10:30:33.731:6) : pid=1 uid=root > > > auid=unset tty=(none) ses=unset subj=kernel comm=systemd > > > exe=/usr/lib/systemd/systemd nl-mcgrp=1 op=connect res=yes > > > > > > And the events from the test suite: > > > > > > type=PROCTITLE msg=audit(2020-01-17 10:36:24.050:294) : > > > proctitle=/usr/bin/perl -w amcast_joinpart/test type=SOCKADDR > > > msg=audit(2020-01-17 10:36:24.050:294) : saddr={ saddr_fam=netlink > > > nlnk-fam=16 nlnk-pid=0 } type=SYSCALL msg=audit(2020-01-17 > > > 10:36:24.050:294) : arch=x86_64 syscall=bind success=yes exit=0 a0=0x7 > > > a1=0x55d65cb79090 a2=0xc a3=0x0 items=0 ppid=671 pid=674 auid=root > > > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > > > fsgid=root tty=ttyS0 ses=3 comm=perl exe=/usr/bin/perl > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) > > > type=UNKNOWN[1335] msg=audit(2020-01-17 10:36:24.050:294) : pid=674 > > > uid=root auid=root tty=ttyS0 ses=3 > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=perl > > > exe=/usr/bin/perl nl-mcgrp=1 op=connect res=yes > > > > > > type=UNKNOWN[1335] msg=audit(2020-01-17 10:36:24.051:295) : pid=674 > > > uid=root auid=root tty=ttyS0 ses=3 > > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=perl > > > exe=/usr/bin/perl nl-mcgrp=1 op=disconnect res=yes> > > > Please see the upstream issue tracker: > > > https://github.com/linux-audit/audit-kernel/issues/28 > > > https://github.com/linux-audit/audit-kernel/wiki/RFE-Audit-Multicast-So > > > cket-Join-Part > > > https://github.com/rgbriggs/audit-testsuite/compare/ghak28-mcast-part-> > join> > > > Signed-off-by: Richard Guy Briggs > > > > > > --- > > > Note: msg type 1334 was skipped due to BPF accepted in another tree. > > > Note: v5 due to previous 2014-10-07, 2015-07-23, 2016-11-30, 2017-10-13 > > > Note: subj attrs included due to missing syscall record for systemd > > > (audit=1) Note: tried refactor of subj attrs, but this is yet another > > > new order. --- > > > > > > include/uapi/linux/audit.h | 1 + > > > kernel/audit.c | 48 > > > ++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 45 > > > insertions(+), 4 deletions(-) > > > > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > > > index 3ad935527177..67fb24472dc2 100644 > > > --- a/include/uapi/linux/audit.h > > > +++ b/include/uapi/linux/audit.h > > > @@ -116,6 +116,7 @@ > > > > > > #define AUDIT_FANOTIFY 1331 /* Fanotify access decision */ > > > #define AUDIT_TIME_INJOFFSET 1332 /* Timekeeping offset injected */ > > > #define AUDIT_TIME_ADJNTPVAL 1333 /* NTP value adjustment */ > > > > > > +#define AUDIT_EVENT_LISTENER 1335 /* Task joined multicast read > > > socket */> > > > #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 17b0d523afb3..478259f3fa53 100644 > > > --- a/kernel/audit.c > > > +++ b/kernel/audit.c > > > @@ -1520,20 +1520,60 @@ static void audit_receive(struct sk_buff *skb) > > > > > > audit_ctl_unlock(); > > > > > > } > > > > > > +/* Log information about who is connecting to the audit multicast socket > > > */ +static void audit_log_multicast_bind(int group, const char *op, int > > > err) +{ > > > + const struct cred *cred; > > > + struct tty_struct *tty; > > > + char comm[sizeof(current->comm)]; > > > + struct audit_buffer *ab; > > > + > > > + if (!audit_enabled) > > > + return; > > > + > > > + ab = audit_log_start(audit_context(), GFP_KERNEL, > > > AUDIT_EVENT_LISTENER); + if (!ab) > > > + return; > > > + > > > + cred = current_cred(); > > > + tty = audit_get_tty(); > > > + audit_log_format(ab, "pid=%u uid=%u auid=%u tty=%s ses=%u", > > > + task_pid_nr(current), > > > + from_kuid(&init_user_ns, cred->uid), > > > + from_kuid(&init_user_ns, > > > audit_get_loginuid(current)), + tty ? > > > tty_name(tty) : "(none)", > > > + audit_get_sessionid(current)); > > > > Don't we already get all of that information as part of the syscall record? > > We don't want or need a syscall record. It doesn't add anything to the > necessary information. Also, when we have syscall records, people expect that > they obey the syscall auditing. Especially wrt "never" audit rules. Did both of you see the 4 "Note:" lines between the description and the patch? I'm caught in the middle here. > > > + audit_put_tty(tty); > > > + audit_log_task_context(ab); /* subj= */ > > > > Also part of the syscall record. > > > > > + audit_log_format(ab, " comm="); > > > + audit_log_untrustedstring(ab, get_task_comm(comm, current)); > > > > Again. > > > > > + audit_log_d_path_exe(ab, current->mm); /* exe= */ > > > > Again. > > > > > + audit_log_format(ab, " nl-mcgrp=%d op=%s res=%d", group, op, > > > !err); > > This part is new ;) > > > > > + audit_log_end(ab); > > > +} > > > > I'm pretty sure these are the same arguments I made when Steve posted > > a prior version of this patch. > > No. You didn't mind it then. What you objected to was that I wrote a helper > function that could be used by future audit events to start a format > standardization process. Again, see the 4 notes. I was not able to refactor any of the subject attributes since this is yet another audit subject attributes order (YAASAO) that hasn't been seen yet. Why are we creatting YAASAO? > The event looks good to me. Ack for the format being acceptable to existing > tools. > > -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