Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5264944ybl; Wed, 22 Jan 2020 13:30:44 -0800 (PST) X-Google-Smtp-Source: APXvYqyzAWC2aDEDYTCLTnI/3pZFi/oxlVkwBHSclP7IcF+G59Yj4lsSKsKBN2pr6raFOdgbOLaf X-Received: by 2002:a05:6808:2ce:: with SMTP id a14mr8400732oid.82.1579728644864; Wed, 22 Jan 2020 13:30:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579728644; cv=none; d=google.com; s=arc-20160816; b=dsTQQIOXk2u6q8Uy3ajoNPcifH5CTqdLTSoh1W/NeGW9MxOg3CSSYKs1ZGvWLI7gzJ X/8OlZvgzy6wl+h7wqa4MUz49aBiEQK1s2pQE9+dKpNh8QkZfJId9Z+RfzP7M/P3zhoA 6P+aM/QzX0GNZXq5MCsqqRMYjHmHm0sSmLAp4JRQSLoTrvTJnHqQwjAqXPKarZTDHI7s LBbRhjF7omAWO9X+gnRYcAWkGQS4oq3MvqIDyPfcNucJLDNwRBCEzKyPOc4HuoRiPTLg TqKob9ZcxIumyiS7bwVn6o4i0fNG2B2uhwneh8pkv9x3hgK8O2pOgKYw7wzlI10n5lpX RDDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=USiqOlQcAGwAU4lLldkez+ILA+mr5UwSGgb0G/ckznI=; b=iS7NeLVMqHcSkRFrtmqbGHyMmIZztAPoTXoOBCtOfwWLO28mabADUfB2gwmejDmLcx o8sSqXQkK5hxpwp+VDJr0rJ61z3ytk79f0r4j8R2/DqyY8VAoo7WMCZK5ToBGWEIg5IY kamlNDzdJeNUKUAFqI+maMlv4dpD8RWG7oziuQ1PNFtk4JLUnvAGEQrB+68VqyPOryht XJlfNpCM3wMhJPIuQ7+eA5krjrzRw4bK4IqkrajinoyllWfGS3a+Sc2tAH7Tc9Wv2iHY igsBnHGoJcbtLV3asnhcw6DxR+ZJfFkPmdbIPb9rShISVSRvSF1Dm3V2TKGQW0y8keUA acaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="QS/qOUvd"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m26si864otn.307.2020.01.22.13.30.26; Wed, 22 Jan 2020 13:30:44 -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=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b="QS/qOUvd"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729271AbgAVV2x (ORCPT + 99 others); Wed, 22 Jan 2020 16:28:53 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:44184 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729251AbgAVV2w (ORCPT ); Wed, 22 Jan 2020 16:28:52 -0500 Received: by mail-lj1-f194.google.com with SMTP id q8so679374ljj.11 for ; Wed, 22 Jan 2020 13:28:51 -0800 (PST) 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=USiqOlQcAGwAU4lLldkez+ILA+mr5UwSGgb0G/ckznI=; b=QS/qOUvdayAU3GPaH8DxPbsbrNRZDZgVX+N4uafont01yWgzRvNuaFkQixghM4fGLg 9QPae3sdC8aYt6XfPuKVLoGF3M3eLlanCkm7mOTAim8uX1TjswA7LDLLQU14TffVzWdL Gy9J9dPV8pMcDKfo7PBT20X86WJTDcuCysfZzYiyO8iVVUDKmXXQ13+YWtnAV8YsOto3 3Ty31Pi58oev8GCNTTYg+MQWArZpl218/1U4l+ULrfBMQSKpN5zG0Cig5Syq7cV4Xzcb +acWuAjXOi/UTiHtnm0IyK6exGOs32jN8dCIv/3RCJnZy70o6IozMJs4uAFIHKeXAuLW +jjQ== 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=USiqOlQcAGwAU4lLldkez+ILA+mr5UwSGgb0G/ckznI=; b=umsaehnlwGyFQiT5aVde2l+nzBMheMZKE0s8tm3uA2mAScxTVNtAHonbw5MzYGbjg5 8VhRl89+ezpoqiTf3Fpe2346WtTQUVn/0yPRBto9ooW3cD6FHmJ0xyixukyD0ZJY8ObC NNkj5XXBQ7UZeTOc72yQswmMSIc4BHTF5id3OJSXrg1vqVzMXVQ6SypqZPk8NmX9byvJ DVKG3nCvR83YIVz1NXIy11igioFoMi3a8HE72qTKRERkXoGfdswlMYL7J/hS1LRGlN2V fqH8TOtq3ena5gHpDdpeYUe4R8NJSLWSmYS9yCTvO4Bv2md7NjWHL8FEi0lDAYvq546W SB4g== X-Gm-Message-State: APjAAAW9ypcWHgTUCGL5GaXHONfD24GlHu+KGfsmVrkvhqcm2Xq19EpU m7+ffE9q/+9GN1LKnHILe9UoNiRxhERhCEdk0tmr X-Received: by 2002:a2e:870b:: with SMTP id m11mr20501589lji.93.1579728530781; Wed, 22 Jan 2020 13:28:50 -0800 (PST) MIME-Version: 1.0 References: <7d7933d742fdf4a94c84b791906a450b16f2e81f.1577736799.git.rgb@redhat.com> In-Reply-To: <7d7933d742fdf4a94c84b791906a450b16f2e81f.1577736799.git.rgb@redhat.com> From: Paul Moore Date: Wed, 22 Jan 2020 16:28:39 -0500 Message-ID: Subject: Re: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon To: Richard Guy Briggs Cc: containers@lists.linux-foundation.org, linux-api@vger.kernel.org, Linux-Audit Mailing List , linux-fsdevel@vger.kernel.org, LKML , netdev@vger.kernel.org, netfilter-devel@vger.kernel.org, sgrubb@redhat.com, omosnace@redhat.com, dhowells@redhat.com, simo@redhat.com, Eric Paris , Serge Hallyn , ebiederm@xmission.com, nhorman@tuxdriver.com, Dan Walsh , mpatel@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 31, 2019 at 2:50 PM Richard Guy Briggs wrote: > > Add audit container identifier support to the action of signalling the > audit daemon. > > Since this would need to add an element to the audit_sig_info struct, > a new record type AUDIT_SIGNAL_INFO2 was created with a new > audit_sig_info2 struct. Corresponding support is required in the > userspace code to reflect the new record request and reply type. > An older userspace won't break since it won't know to request this > record type. > > Signed-off-by: Richard Guy Briggs > --- > include/linux/audit.h | 7 +++++++ > include/uapi/linux/audit.h | 1 + > kernel/audit.c | 35 +++++++++++++++++++++++++++++++++++ > kernel/audit.h | 1 + > security/selinux/nlmsgtab.c | 1 + > 5 files changed, 45 insertions(+) ... > diff --git a/kernel/audit.c b/kernel/audit.c > index 0871c3e5d6df..51159c94041c 100644 > --- a/kernel/audit.c > +++ b/kernel/audit.c > @@ -126,6 +126,14 @@ struct auditd_connection { > kuid_t audit_sig_uid = INVALID_UID; > pid_t audit_sig_pid = -1; > u32 audit_sig_sid = 0; > +/* Since the signal information is stored in the record buffer at the > + * time of the signal, but not retrieved until later, there is a chance > + * that the last process in the container could terminate before the > + * signal record is delivered. In this circumstance, there is a chance > + * the orchestrator could reuse the audit container identifier, causing > + * an overlap of audit records that refer to the same audit container > + * identifier, but a different container instance. */ > +u64 audit_sig_cid = AUDIT_CID_UNSET; I believe we could prevent the case mentioned above by taking an additional reference to the audit container ID object when the signal information is collected, dropping it only after the signal information is collected by userspace or another process signals the audit daemon. Yes, it would block that audit container ID from being reused immediately, but since we are talking about one number out of 2^64 that seems like a reasonable tradeoff. -- paul moore www.paul-moore.com