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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1CDDEC433F5 for ; Wed, 12 Jan 2022 21:47:07 +0000 (UTC) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-44-NeK10pS7OQ6o-42Wv9Y-JQ-1; Wed, 12 Jan 2022 16:47:03 -0500 X-MC-Unique: NeK10pS7OQ6o-42Wv9Y-JQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2523681CCB7; Wed, 12 Jan 2022 21:46:59 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E5AEB78C1C; Wed, 12 Jan 2022 21:46:58 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 3DF161809CB8; Wed, 12 Jan 2022 21:46:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 20CLksnl017974 for ; Wed, 12 Jan 2022 16:46:54 -0500 Received: by smtp.corp.redhat.com (Postfix) id 8DAA04047281; Wed, 12 Jan 2022 21:46:54 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8941D4047272 for ; Wed, 12 Jan 2022 21:46:54 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 655163C14635 for ; Wed, 12 Jan 2022 21:46:54 +0000 (UTC) Received: from sonic315-27.consmr.mail.ne1.yahoo.com (sonic315-27.consmr.mail.ne1.yahoo.com [66.163.190.153]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-122-F2bx-43pNVOBSBbv2UyPIg-1; Wed, 12 Jan 2022 16:46:51 -0500 X-MC-Unique: F2bx-43pNVOBSBbv2UyPIg-1 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642024010; bh=XshAzZb06/Xs3IExOokHeDxn4do6VYvVDbttwXYx6+0=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=bijQuHCeF7hNMITmS15ETOqyE/kpEtKJyuvHlOlkuiR4aeXD45wyZpkK4xxSeYC3P6qO0Y+VCd+p6DjL8+IqK1uDFzf7kup+oA1C9fe4eYN2TIckPY0lCYVa8wE2LClVK2D2uRKnMzVplIrQ39V7B+0DPtLHaHpN8iD2yIwVuTnUOcMRRMtdGHCb20KKI6VPa53mjA8UbEY+QbGi2ucz3JqHnkewVM2q7wPY/AEX4djQotnY2XRrLsb01WB7sEtETbzqLFe3XGpsHaQKEViF1GTsYwlFa/XGpMdpCBdZheZJtEwFo5fu/drMLztuVzGCBkYV0n4ZMmHNYpmOOC+w8Q== X-YMail-OSG: IgI8gTAVM1n8MYtnkxx9dm2aYfoZIAwdTqlVZg4mV48HAiMmNCyukalBAtIJVSa wDcVNk.SosdSWC6o9FVnI.H0k0i79qoZcXJilogFNg2WRDQwSU296VivDaRonXogRFtYkTtgam96 7Dp57FVwBEjqkC1fudZR5P6fn9FaTQqwv4peeLuxv7wI_DYVw7s9SJCFLvhzO7qwV.EtZq_J.DNZ FJaYy_cPTrALi6t_LWK3rFlCOKJYFstm0KxSqZX..qqHNgD_TpYcvgTGDc.PRcMhyDp99RJ0Wgos l_hG.mVySqdNSMV_xWmdpj43rhal5Km5pu8R1MkPDVzQjLuTa9B0WipbVQHMHSM0BsZPb_x0KevT 0qwfmw24VifwacwVPLpRNeoiJyBwnDzwRWdHEIOzyjDVaDXfb8USV92OLzIZ46cVnvnblSJ8Z4Zp jbDvYMJKqwT64siDq7hl0Hogatmv7CZSWVN_AJByIlisIV8M1KUW6_NnDzVbRB7EnXI9FB5p.JaQ 5.RWx2QT_yYmCDiPtX6VzF4rSinHgtzjn29aRzlJdTqciYhj27eC2FFf0JSOyNo2e2kyV3ktUlZv 1zMN0jFy.awCUwB9723ZJ2IGuigGwklfyFn1OQHqcngNkn78LqTxe0wr0Z_MXGsxeffclaX4kVJq a6bp8XBpQYP8Bzl6SAK3p5R28dfZZHtb0Q4EzCLsuwpiK7PTYZO3PUnpnNPU82A44fQBbA0r9c.D 1mU1Clt2z5SuCex0si4unxYZewSCvW1XiOm6wCriP.Q2GyEXMSsxkuni7pkB0O9Df0Xj126ncqKb HIbk9cgK4sLrizptelQnHuslEj_nNTCKk9faFsCwahSA0JBqv0aTMU9UPK2LMCY.sTsZdZNCK.gV tw3GuX52jt4PgfS6mPBuU0tFFKzfqMDryPS8pC4FmC830NJcXIcCE6TLpRrPuji3cSJa1m.N35s_ 6rTaCtmbJZNkTwYtZYW7uebBllSS4zdsZXHVM3jsaQ6sWgm1k25HlXDXr7n8MsiwHt6b1eJ0PZ0E GXNAAAWNy4JKwsJmBAC9G3pM916PK6bi7ZKitrS.PVuBUXoQW0fUkYqCPkCn8MpVtwXmvL1azuaA VNbD_5Y3JHPxCNobWh.ens3BC4Vkbt7KBHPm6lv8qjqjAzLAFRu7DWxL9Mlyf7c1NrzZrW9DG82u EU.9NmOwPKtSLC8RoMaptwUmk5dbyZGuujbHHCndOlbvOiImNORMnRz0QkXpYEHpy0s9A_XHt5S. T1c4Dz6P20YBGcbIFmd4rCc32PrCysbxiSroed015v_kP_Dl9SsAHCUfm8J8nXxeiUX8gCl5oxCr 6R6JF3E9mDCITZbF8928d.Q6ZRRV4kx8MWx8GFZ6U.XO6iHxatGI0CejL4F32o_EGCIzoOeP9hi7 UJeaC9UvU5k3V5CSE6GQuJq4SBqVZ8RoGxu0nz5UhyPj30vyafSreskc8f1uVJXgnozSPV1C7CfI cbaEjwrhkwmr2w6bIDGIS2PFQhJkHXO3eV12k1nl22QBrQDf7UbgRSCmIHz391vu4pI3oDUgVXwc WN1rxefRLPrv_RUb8N60f1zG8Fb27hfnqot5anmTidu.vAs9vKJtqYSZV9tKRgdDsS4lPY1NdM46 sAVYtYEO9K6oZ1hnFc_zGtOWGBchJ_yGREzZFx3hVwom.un8t11qANvG9jfzieGsDfEK9aGVu79k 5d7Azscpv5DSWHaCH0GnhlmjwJySIae7IwmNRkH4sGjhQ6PrtAiCQtzf5O7EBCjtB.RUnkA7_UCX c_XX.YNdoty0cLrfx1vyV7nv.SraLKyahIlavJZyHCVSfNhgLALhuazOXR67db92mYbP_qpgjfWD FpGuZq59b0S7DLGQFFuaUy730OLfFtOtmC61o_wBvA8q1jd0Jy.KQ5bk.0lclMIpFQKgFOPPMBEf kEE8LeA60mya5BsI2VwBy6g6pIqvSiXTERPjnspqL4J5uki9A5yHfqgPN0mVIxB1T.SzpVfnve7U EAxFVCC8.PXlKHp.hXFPc5zmnbqJc6IyoOzsYzsxDag7fyex8sr_7CECn82YcmAbU.YLzHmyD4SE XMQBCU9RfneEtS0FUJIvl2OH2HGwz4kN_wewn29OGbmRLXGbus5KRCTLLZbM3cGsc_64qRtc77nb oMHkv4D12hohEMbmr2r4_k2k1n0EsSOpl3Bv6R1toytWoLrmXpGyUrKEuD8TnXOS7exwDaM9qymb LXRZry5XNhWPim8Za0UqC7yWlFm_bDaAWdwm8jX2jLR_SzTCjKhaf1WOJf6tyXuLacWuIGQnnczW qT4KuOP3KMI9.mENaSnH2uK6cLTg- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Wed, 12 Jan 2022 21:46:50 +0000 Received: by kubenode537.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID dbcdc0f146a6a7a7998826fe17d691ad; Wed, 12 Jan 2022 21:46:45 +0000 (UTC) Message-ID: <3ba69e5e-ca20-a36d-7668-7df0732eee46@schaufler-ca.com> Date: Wed, 12 Jan 2022 13:46:43 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [RFC PATCH v1] audit: log AUDIT_TIME_* records only from rules To: Richard Guy Briggs , Paul Moore References: <20220112210622.GC1550715@madcap2.tricolour.ca> From: Casey Schaufler In-Reply-To: <20220112210622.GC1550715@madcap2.tricolour.ca> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 X-loop: linux-audit@redhat.com Cc: Eric Paris , Linux-Audit Mailing List X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=linux-audit-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" On 1/12/2022 1:06 PM, Richard Guy Briggs wrote: > On 2021-12-29 17:51, Paul Moore wrote: >> On Thu, Nov 4, 2021 at 5:00 PM Richard Guy Briggs wrote: >>> AUDIT_TIME_* events are generated when there are syscall rules present that are >>> not related to time keeping. This will produce noisy log entries that could >>> flood the logs and hide events we really care about. >>> >>> Rather than immediately produce the AUDIT_TIME_* records, store the data and >>> log it at syscall exit time respecting the filter rules. >>> >>> Please see https://bugzilla.redhat.com/show_bug.cgi?id=1991919 >>> >>> Signed-off-by: Richard Guy Briggs >>> --- >>> Note: This is a quick and dirty proof-of-concept. If this approach of >>> storing the values in the audit_context for later filtering is >>> acceptable I'll clean up the patch (re-name functions) and re-submit. >>> >>> kernel/audit.h | 6 ++++++ >>> kernel/auditsc.c | 29 +++++++++++++++++++++++++---- >>> 2 files changed, 31 insertions(+), 4 deletions(-) >> Reviewing this now with a more critical eye since it is longer just a >> quick-n-dirty proof of concept ... >> >>> diff --git a/kernel/audit.h b/kernel/audit.h >>> index 3b64a97f6091..25d63731b0e0 100644 >>> --- a/kernel/audit.h >>> +++ b/kernel/audit.h >>> @@ -196,6 +196,12 @@ struct audit_context { >>> struct { >>> char *name; >>> } module; >>> + struct { >>> + struct audit_ntp_data data; >>> + } ntp; >>> + struct { >>> + struct timespec64 injoffset; >>> + } tk; >> With the ntp and tk structs being separate parts of a union, are we >> going to have a problem when ADJ_SETOFFSET is set in a call to >> do_adjtimex()? > Yes, so since both record types can exist in one event, either both > pieces of data will need to be in one struct within the union, or > one piece of data will need to go outside of the union (preferably the > smaller one to avoid bloating struct audit_context more than necessary). > The tk data is smaller and is easier to check if it is set, so that > might be better to store outside the union. > > Since show_special is keyed off record type, it makes more sense to > store one of those datum outside the union and process it outside > show_special to avoid record type tricks in show_special. In the LSM stacking patch set I've implemented a list of auxiliary data elements for supplemental records. That would address these issues and provide the general mechanism we're going to need regardless. > >>> }; >>> int fds[2]; >>> struct audit_proctitle proctitle; >>> diff --git a/kernel/auditsc.c b/kernel/auditsc.c >>> index 6efb0bb909d0..8983790ad86a 100644 >>> --- a/kernel/auditsc.c >>> +++ b/kernel/auditsc.c >>> @@ -1210,11 +1210,18 @@ static void audit_log_fcaps(struct audit_buffer *ab, struct audit_names *name) >>> from_kuid(&init_user_ns, name->fcap.rootid)); >>> } >>> >>> +void __audit_ntp_log_(const struct audit_ntp_data *ad); >>> + >>> static void show_special(struct audit_context *context, int *call_panic) >>> { >>> struct audit_buffer *ab; >>> int i; >>> >>> + if (context->type == AUDIT_TIME_ADJNTPVAL) { >>> + __audit_ntp_log_(&context->ntp.data); >>> + return; >>> + } >> Can we find a way to move this down into the main switch statement in >> show_special() like you did with AUDIT_TIME_INJOFFSET? This looks >> *really* hacky to me. Why should AUDIT_TIME_ADJNTPVAL be different >> from the other "special" bits? > Agreed, it *looked* hacky to me too. As previously noted, this was the > most expedient way to do this due to the unknown number of records being > generated, minimum of zero (max 6). show_special allocates an > audit_buffer before processing the specific record type, assuming it > exists. In the case of audit_ntp_data, it may all be equal and not need > to be logged. > > Ideally, the old vs new data should be compared at the time of the call > from do_adjtimex() to find out if we even need to store that data > when all old and new values are equal. > > So, a bit more pre-processing during the call to avoid storing the > information if it isn't needed will avoid it at syscall exit. Are you > ok with that? > >>> ab = audit_log_start(context, GFP_KERNEL, context->type); >>> if (!ab) >>> return; >>> @@ -1324,6 +1331,11 @@ static void show_special(struct audit_context *context, int *call_panic) >>> audit_log_format(ab, "(null)"); >>> >>> break; >>> + case AUDIT_TIME_INJOFFSET: >>> + audit_log_format(ab, "sec=%lli nsec=%li", >>> + (long long)context->tk.injoffset.tv_sec, >>> + context->tk.injoffset.tv_nsec); >>> + break; >>> } >>> audit_log_end(ab); >>> } >>> @@ -2571,9 +2583,18 @@ void __audit_fanotify(unsigned int response) >>> >>> void __audit_tk_injoffset(struct timespec64 offset) >>> { >>> - audit_log(audit_context(), GFP_KERNEL, AUDIT_TIME_INJOFFSET, >>> - "sec=%lli nsec=%li", >>> - (long long)offset.tv_sec, offset.tv_nsec); >>> + struct audit_context *context = audit_context(); >>> + >>> + context->type = AUDIT_TIME_INJOFFSET; >>> + memcpy(&context->tk.injoffset, &offset, sizeof(offset)); >>> +} >>> + >>> +void __audit_ntp_log(const struct audit_ntp_data *ad) >>> +{ >>> + struct audit_context *context = audit_context(); >>> + >>> + context->type = AUDIT_TIME_ADJNTPVAL; >>> + memcpy(&context->ntp.data, ad, sizeof(*ad)); >>> } >>> >>> static void audit_log_ntp_val(const struct audit_ntp_data *ad, >>> @@ -2588,7 +2609,7 @@ static void audit_log_ntp_val(const struct audit_ntp_data *ad, >>> "op=%s old=%lli new=%lli", op, val->oldval, val->newval); >>> } >>> >>> -void __audit_ntp_log(const struct audit_ntp_data *ad) >>> +void __audit_ntp_log_(const struct audit_ntp_data *ad) >>> { >>> audit_log_ntp_val(ad, "offset", AUDIT_NTP_OFFSET); >>> audit_log_ntp_val(ad, "freq", AUDIT_NTP_FREQ); >> Ooof, *please* don't end a function, or any symbol for that matter, >> with an underscore. > Ok, renamed to be consistent with others called from show_special(). > >> 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 > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://listman.redhat.com/mailman/listinfo/linux-audit > -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit