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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 46C65C4338F for ; Thu, 19 Aug 2021 00:47:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C0CE60F57 for ; Thu, 19 Aug 2021 00:47:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234778AbhHSAsR (ORCPT ); Wed, 18 Aug 2021 20:48:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234744AbhHSAsR (ORCPT ); Wed, 18 Aug 2021 20:48:17 -0400 Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3346C0613CF for ; Wed, 18 Aug 2021 17:47:41 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id gt38so8843299ejc.13 for ; Wed, 18 Aug 2021 17:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n3118yHZBGo6DRzRXBqG3ftlGaa+KyJKRgYLmI/eYAI=; b=ODY/2RDrQWGsGpgT+Y2j7ZtLc8aOfrKuoS37Pp/TOPHfExYYe//wDgXm5uZEFPpNcE blOCp9cFdhz+h+xkHnF2WqBNLkRcASpltA6eapWAtov8YirRNCm01ODgKigeNrjcuqKL VZ3gvxXqcTLbziY64RDiO9PUXO8XM/rodECa1RBRIY3Qj8nUD7kUPo2tVHXtbKlqeeQB 3plvVKmJDK2Hc9OGSjyld8qr91VZVtR+F2F8B1jX1hJqGfx8eBDUREYZhWIMjOSrN4md gAwo6QppkjT6UIU1WRoLqE4cdXjATrPzYEkC9vky3/aQ/d90PeUyEx1cM1eajc3rQy3M TvUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n3118yHZBGo6DRzRXBqG3ftlGaa+KyJKRgYLmI/eYAI=; b=Yxb8l2B2Juvs1E5mbecMZ86aZ5tzx/Y/Uo+sBHVyGzfR57pcuOnexewHtir8l1s9Ok LP3wrxXu77fFsc/IvegZBumO50JFkT7XIQVC2rYMMPEk65HaSJkwlxdW+pekKLFvXCpp kU00LyKmeEmfXnL6a6ZrjJYwitumqKmbDAs1eTFEuANOmtiC5hsiURMoLrCQU6ho26LY hi593FkvjdZH7XSNi5aTxJKAdErPAn+iLMuwtWXfGLVvYnG9kufWKlRKYXf1Qb+XgtXw ZefAfcsPfj5ZPx7VxYA8E4qC9n170XD1M47tMDJCWiRJw2CR6dQBLjqRxsUZ6RgvCFeT 92iA== X-Gm-Message-State: AOAM533d6/EVewZjj6l9joi2ee8pJLrjI0PhPng84mgjvxojdTncdHvP FxcbAqB+Cn9tzcdlsxd7FOLjZMIKc/m4jNFuRamQ X-Google-Smtp-Source: ABdhPJxUhG6RMHG8hWBMBx9UdS8uXzdLCCmnu/rsRxmxhGzDLA3tVGwIkTsYw0JMOGWrJ57On2kUIZFxTiG1hRC+Pv4= X-Received: by 2002:a17:906:2755:: with SMTP id a21mr12347619ejd.488.1629334060204; Wed, 18 Aug 2021 17:47:40 -0700 (PDT) MIME-Version: 1.0 References: <20210722004758.12371-1-casey@schaufler-ca.com> <20210722004758.12371-23-casey@schaufler-ca.com> <3ebad75f-1887-bb31-db23-353bfc9c0b4a@schaufler-ca.com> <062ba5f9-e4e8-31f4-7815-826f44b35654@schaufler-ca.com> In-Reply-To: <062ba5f9-e4e8-31f4-7815-826f44b35654@schaufler-ca.com> From: Paul Moore Date: Wed, 18 Aug 2021 20:47:29 -0400 Message-ID: Subject: Re: [PATCH v28 22/25] Audit: Add record for multiple process LSM attributes To: Casey Schaufler Cc: casey.schaufler@intel.com, James Morris , linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-audit@redhat.com, keescook@chromium.org, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, Stephen Smalley Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Wed, Aug 18, 2021 at 5:59 PM Casey Schaufler wrote: > > On 8/16/2021 11:57 AM, Paul Moore wrote: > > On Fri, Aug 13, 2021 at 5:47 PM Casey Schaufler wrote: > >> On 8/13/2021 1:43 PM, Paul Moore wrote: > ... > > Yeah, the thought occurred to me, but we are clearly already in the > > maybe-the-assumptions-are-wrong stage so I'm not going to rely on that > > being 100%. We definitely need to track this down before we start > > making to many more guesses about what is working and what is not. > > I've been tracking down where the audit context isn't set where > we'd expect it to be, I've identified 5 cases: > > 1000 AUDIT_GET - Get Status > 1001 AUDIT_SET - Set status enable/disable/auditd > 1010 AUDIT_SIGNAL_INFO > 1130 AUDIT_SERVICE_START > 1131 AUDIT_SEVICE_STOP > > These are all events that relate to the audit system itself. > It seems plausible that these really aren't syscalls and hence > shouldn't be expected to have an audit_context. I will create a > patch that treats these as the special cases I believe them to be. Yes, all but two of these could be considered to be audit subsystem control messages, but AUDIT_SERVICE_{START,STOP} I think definitely fall outside the audit subsystem control message category. The AUDIT_SERVICE_{START,STOP} records are used to indicate when a service, e.g. NetworkManager, starts and stops; on my fedora test system they are generated by systemd since it manages service state on that system; a quick example is below, but I'm sure you've seen plenty of these already. % ausearch -m SERVICE_START time->Wed Aug 18 20:13:00 2021 type=SERVICE_START msg=audit(1629331980.779:1186): pid=1 uid=0 auid=4294967295 s es=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatch er comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? re s=success' However, regardless of if the message is related to controlling the audit subsystem or not, we do want to be able to associate those records with other related records, e.g. SYSCALL records. Looking at the message types you listed above, they are all records that are triggered by userspace via netlink messages; if you haven't already I would start poking along that code path to see if something looks awry. I just spent a few minutes tracing the code paths up from audit through netlink and then through the socket layer and I'm not seeing anything obvious where the path differs from any other syscall; current->audit_context *should* be valid just like any other syscall. However, I do have to ask, are you only seeing these audit records with a current->audit_context equal to NULL during early boot? -- paul moore www.paul-moore.com 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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 83E89C4338F for ; Thu, 19 Aug 2021 00:47:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 07CC760F57 for ; Thu, 19 Aug 2021 00:47:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 07CC760F57 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=redhat.com 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-418-lfxyH2UmNTu8L6f3K2bmOA-1; Wed, 18 Aug 2021 20:47:55 -0400 X-MC-Unique: lfxyH2UmNTu8L6f3K2bmOA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CCA098799E0; Thu, 19 Aug 2021 00:47:51 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 372CE1ABD7; Thu, 19 Aug 2021 00:47:51 +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 E69B94BB7C; Thu, 19 Aug 2021 00:47:49 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 17J0llQC007175 for ; Wed, 18 Aug 2021 20:47:47 -0400 Received: by smtp.corp.redhat.com (Postfix) id 68C10207B2CF; Thu, 19 Aug 2021 00:47:47 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 645AB207B33D for ; Thu, 19 Aug 2021 00:47:44 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (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 D4448801E6D for ; Thu, 19 Aug 2021 00:47:44 +0000 (UTC) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-529-G5fscYuzMrC9qkVRYOClLw-1; Wed, 18 Aug 2021 20:47:42 -0400 X-MC-Unique: G5fscYuzMrC9qkVRYOClLw-1 Received: by mail-ej1-f52.google.com with SMTP id x11so9075538ejv.0 for ; Wed, 18 Aug 2021 17:47:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n3118yHZBGo6DRzRXBqG3ftlGaa+KyJKRgYLmI/eYAI=; b=Zo+VsON31ah/+efhHtHRpfyh08tZFrQ3A9SWzWyl6OZxipHBniYBUNGgQaEwqQLEn+ p599nrcv0Ict3aiU8C7FrHMA7xvmu85zdzrgTF5BUNGyGIm3jv9LPemIkFbc3OPVoLpG JARBxRB9vrt5RkxA/o2KymixTuHFpNNjB+L4xxWYpsE6sCsXqxkEJrI6YzK4/ZXa7n/R B7au0W+J4pSHPevk49hiLJb1+4q5YL4oUUGjtDABsI3sGZbNXQsgRU05VjFIcqIrlLLD UT6SGyIagPPYPAkZh+EsMUZreG72B/pt7Mx0rkWnVmE1z7iTmwSPZtV2R7YZnalsv2CU 8+LQ== X-Gm-Message-State: AOAM531AW9azubA4cBqi357PvELNSP9MxVR7xV1bus9rYpImxsIr9wxp g7wXqjYniWetixgBT5ghocA4rr5qgyEadL7DJ1OgJkxm6+hXrQ8= X-Google-Smtp-Source: ABdhPJxUhG6RMHG8hWBMBx9UdS8uXzdLCCmnu/rsRxmxhGzDLA3tVGwIkTsYw0JMOGWrJ57On2kUIZFxTiG1hRC+Pv4= X-Received: by 2002:a17:906:2755:: with SMTP id a21mr12347619ejd.488.1629334060204; Wed, 18 Aug 2021 17:47:40 -0700 (PDT) MIME-Version: 1.0 References: <20210722004758.12371-1-casey@schaufler-ca.com> <20210722004758.12371-23-casey@schaufler-ca.com> <3ebad75f-1887-bb31-db23-353bfc9c0b4a@schaufler-ca.com> <062ba5f9-e4e8-31f4-7815-826f44b35654@schaufler-ca.com> In-Reply-To: <062ba5f9-e4e8-31f4-7815-826f44b35654@schaufler-ca.com> From: Paul Moore Date: Wed, 18 Aug 2021 20:47:29 -0400 Message-ID: Subject: Re: [PATCH v28 22/25] Audit: Add record for multiple process LSM attributes To: Casey Schaufler 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.78 on 10.11.54.4 X-loop: linux-audit@redhat.com Cc: john.johansen@canonical.com, selinux@vger.kernel.org, James Morris , linux-security-module@vger.kernel.org, linux-audit@redhat.com, casey.schaufler@intel.com, Stephen Smalley 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.15 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Aug 18, 2021 at 5:59 PM Casey Schaufler wrote: > > On 8/16/2021 11:57 AM, Paul Moore wrote: > > On Fri, Aug 13, 2021 at 5:47 PM Casey Schaufler wrote: > >> On 8/13/2021 1:43 PM, Paul Moore wrote: > ... > > Yeah, the thought occurred to me, but we are clearly already in the > > maybe-the-assumptions-are-wrong stage so I'm not going to rely on that > > being 100%. We definitely need to track this down before we start > > making to many more guesses about what is working and what is not. > > I've been tracking down where the audit context isn't set where > we'd expect it to be, I've identified 5 cases: > > 1000 AUDIT_GET - Get Status > 1001 AUDIT_SET - Set status enable/disable/auditd > 1010 AUDIT_SIGNAL_INFO > 1130 AUDIT_SERVICE_START > 1131 AUDIT_SEVICE_STOP > > These are all events that relate to the audit system itself. > It seems plausible that these really aren't syscalls and hence > shouldn't be expected to have an audit_context. I will create a > patch that treats these as the special cases I believe them to be. Yes, all but two of these could be considered to be audit subsystem control messages, but AUDIT_SERVICE_{START,STOP} I think definitely fall outside the audit subsystem control message category. The AUDIT_SERVICE_{START,STOP} records are used to indicate when a service, e.g. NetworkManager, starts and stops; on my fedora test system they are generated by systemd since it manages service state on that system; a quick example is below, but I'm sure you've seen plenty of these already. % ausearch -m SERVICE_START time->Wed Aug 18 20:13:00 2021 type=SERVICE_START msg=audit(1629331980.779:1186): pid=1 uid=0 auid=4294967295 s es=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatch er comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? re s=success' However, regardless of if the message is related to controlling the audit subsystem or not, we do want to be able to associate those records with other related records, e.g. SYSCALL records. Looking at the message types you listed above, they are all records that are triggered by userspace via netlink messages; if you haven't already I would start poking along that code path to see if something looks awry. I just spent a few minutes tracing the code paths up from audit through netlink and then through the socket layer and I'm not seeing anything obvious where the path differs from any other syscall; current->audit_context *should* be valid just like any other syscall. However, I do have to ask, are you only seeing these audit records with a current->audit_context equal to NULL during early boot? -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit