Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp465771pxa; Fri, 21 Aug 2020 11:49:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwl1VUTbfOMTB/vsze2RZ2HLAKPzJw0N+ptCMZZhY5H2T8soFQJ9QgwoO9lJKzc2Rj6XHem X-Received: by 2002:a17:907:42cd:: with SMTP id nz21mr4172820ejb.395.1598035756123; Fri, 21 Aug 2020 11:49:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598035756; cv=none; d=google.com; s=arc-20160816; b=V838JGWoMrF/506EuMhKTjK7KAHqEkuSN3J2v1q5za4v0Z+oMIeayIGBVErTCEi1YZ 5nmkTpwVghwreNC3hi45ma4ZrFKwbheV18oAc/EIOAw3q6JpUse+Mc/mGTSrTyc2MyXa zvjNb1qN7fyDihgASTIT1R0Tseuzu4kDFvPsFro958FDP5TaTVeBdynYi0gl5qZNdRh3 R0BVwR0IBK6vKo0yQcRvznwCz1Oijs+7QOiKlgDutMThe+sXDAVSlJf0WD+t6mJvJrKR TjuBx7nbAdwKh2OkfheIu8O+7ZD/+LV49AaZQ5i9iGgtis3YrQ/oyBaPLSf+AGrfIVye yGIg== 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=zFS0hAClZdBqg1ygZpYSD8oadp4rG9FtsqCxJLGMqfA=; b=08jkGUp38K1FmLT8yV9qiSg7/r9pqwWkux2XpvN19KdSba7sYoENxah/1yfyJig8HZ 2MD8aLjNtE/0cJctuG7RLpzKGscp7Si5n9RmTg0N1nWdwG1pSDj1rhyfCxg2/kUOkfZX Yl1SFCpTUCuNeo3offWDjp2SoP6EPxr6zV9LOrWs5tUK1/Tz32N0xNURnNM4lcx0KmVo FZP31rUlwlcKjMXg1WhAtcn9j93L0FBz1X78nXvkW+jAOHOXvGBaDjtqKdU096MyiZ99 yOcMCIFbXjlRDrBO0o81m4zUEDHWUqcuGs7ZjUzetPgB6+GdERUnPEqYLxvwzIM1W/Ue k6zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=sR7x2B3W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dj4si1836032edb.361.2020.08.21.11.48.50; Fri, 21 Aug 2020 11:49:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=sR7x2B3W; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726431AbgHUSsS (ORCPT + 99 others); Fri, 21 Aug 2020 14:48:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56228 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725821AbgHUSsO (ORCPT ); Fri, 21 Aug 2020 14:48:14 -0400 Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F5C0C061574 for ; Fri, 21 Aug 2020 11:48:14 -0700 (PDT) Received: by mail-ed1-x542.google.com with SMTP id m20so2305296eds.2 for ; Fri, 21 Aug 2020 11:48:14 -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=zFS0hAClZdBqg1ygZpYSD8oadp4rG9FtsqCxJLGMqfA=; b=sR7x2B3WYmbJC0y0bskKUkgCZEZ0j6lJfaOE9m/aD1tPrwC+sndJCJ4t2wQ4hKQfbQ 7FoezsNiRLAR4hKbKjrEMl76ogeQUCZGtDMDP7LxzfEgFbINSDDNYgMAGx1xoEXq3VpN v0MSaBpjMz+kGMMSpn3MoG9Z87EHCAuqGjzax6a4NbGzpiktpJ1dlZ1SY+H8NzLr9EeP RaXaiuPjTpMpdTeUflreO3Gt+Uk4fksOchPjyUfHNBmJ931yTLIpXUOk8bUq2a67QQCy o+VkBqZZx2uUaYQDUr/mQYz9VD5rnYJzHOfyeLpwvLQYSpQ3DMVul1NsBzC3nzxmWEMr GElQ== 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=zFS0hAClZdBqg1ygZpYSD8oadp4rG9FtsqCxJLGMqfA=; b=qUjbs7C5tWkDtjFFLWGlwp5xCAaDfQYYseBaRPnnL0y3GLZ2JB/KEQG4xwzR0yCrfM 4K2pTaNgIVbRvze6biLTRVhW3vtdhMzmgnQR/e2kYq3v0e921YCaAlN1eiA63wppFLrj f6wgWZ/xzTncOti8MjNhb2Zt/wQr9O6v7DsU5gPsC9VUZxvd6UJPzlvK1aKtnTlC9YWG bLKVjOXbc+ljvVlK36iw1TmFXIJE0vIKO/sIsGfWuH6J6HQOWQz55dODxxvoHMszA0o1 iIB4cvfqmD3fjZTP8Ts/QnepMwGrWXiXC19CmXHL+7g/X94IuNa1hzljjUKhpaxg/bQR G15A== X-Gm-Message-State: AOAM5324VD6MCphFfZ6MCZtithW08roOrHQJI8H6MGRr3eEeno/NyEEW 3EeD91dFM891vodZUffNBgDHkfogQQLXoUcWCRPj X-Received: by 2002:a50:ee93:: with SMTP id f19mr4182974edr.31.1598035692549; Fri, 21 Aug 2020 11:48:12 -0700 (PDT) MIME-Version: 1.0 References: <20200729190025.mueangq3os3r7ew6@madcap2.tricolour.ca> In-Reply-To: <20200729190025.mueangq3os3r7ew6@madcap2.tricolour.ca> From: Paul Moore Date: Fri, 21 Aug 2020 14:48:01 -0400 Message-ID: Subject: Re: [PATCH ghak90 V9 06/13] 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, Ondrej Mosnacek , 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 Wed, Jul 29, 2020 at 3:00 PM Richard Guy Briggs wrote: > On 2020-07-05 11:10, Paul Moore wrote: > > On Sat, Jun 27, 2020 at 9:22 AM 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 | 8 ++++ > > > include/uapi/linux/audit.h | 1 + > > > kernel/audit.c | 95 ++++++++++++++++++++++++++++++++++++++++++++- > > > security/selinux/nlmsgtab.c | 1 + > > > 4 files changed, 104 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > > index 5eeba0efffc2..89cf7c66abe6 100644 > > > --- a/include/linux/audit.h > > > +++ b/include/linux/audit.h > > > @@ -22,6 +22,13 @@ struct audit_sig_info { > > > char ctx[]; > > > }; > > > > > > +struct audit_sig_info2 { > > > + uid_t uid; > > > + pid_t pid; > > > + u32 cid_len; > > > + char data[]; > > > +}; > > > + > > > struct audit_buffer; > > > struct audit_context; > > > struct inode; > > > @@ -105,6 +112,7 @@ struct audit_contobj { > > > u64 id; > > > struct task_struct *owner; > > > refcount_t refcount; > > > + refcount_t sigflag; > > > struct rcu_head rcu; > > > }; > > > > It seems like we need some protection in audit_set_contid() so that we > > don't allow reuse of an audit container ID when "refcount == 0 && > > sigflag != 0", yes? > > We have it, see -ESHUTDOWN below. That check in audit_set_contid() is checking ->refcount and not ->sigflag; ->sigflag is more important in this context, yes? > > > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h > > > index fd98460c983f..a56ad77069b9 100644 > > > --- a/include/uapi/linux/audit.h > > > +++ b/include/uapi/linux/audit.h > > > @@ -72,6 +72,7 @@ > > > #define AUDIT_SET_FEATURE 1018 /* Turn an audit feature on or off */ > > > #define AUDIT_GET_FEATURE 1019 /* Get which features are enabled */ > > > #define AUDIT_CONTAINER_OP 1020 /* Define the container id and info */ > > > +#define AUDIT_SIGNAL_INFO2 1021 /* Get info auditd signal sender */ > > > > > > #define AUDIT_FIRST_USER_MSG 1100 /* Userspace messages mostly uninteresting to kernel */ > > > #define AUDIT_USER_AVC 1107 /* We filter this differently */ > > > diff --git a/kernel/audit.c b/kernel/audit.c > > > index a09f8f661234..54dd2cb69402 100644 > > > --- a/kernel/audit.c > > > +++ b/kernel/audit.c > > > @@ -126,6 +126,8 @@ struct auditd_connection { > > > kuid_t audit_sig_uid = INVALID_UID; > > > pid_t audit_sig_pid = -1; > > > u32 audit_sig_sid = 0; > > > +static struct audit_contobj *audit_sig_cid; > > > +static struct task_struct *audit_sig_atsk; > > > > This looks like a typo, or did you mean "atsk" for some reason? > > No, I meant atsk to refer specifically to the audit daemon task and not > any other random one that is doing the signalling. I can change it is > there is a strong objection. Esh, yeah, "atsk" looks too much like a typo ;) At the very leask add a 'd' in there, e.g. "adtsk", but something better than that would be welcome. > > > @@ -2532,6 +2620,11 @@ int audit_set_contid(struct task_struct *task, u64 contid) > > > if (cont->id == contid) { > > > /* task injection to existing container */ > > > if (current == cont->owner) { > > > + if (!refcount_read(&cont->refcount)) { > > > + rc = -ESHUTDOWN; > > > > Reuse -ENOTUNIQ; I'm not overly excited about providing a lot of > > detail here as these are global system objects. If you must have a > > different errno (and I would prefer you didn't), use something like > > -EBUSY. > > I don't understand the issue of "global system objects" since the only > time this error would be issued is if its own contid were being reused > but it hadn't cleaned up its own references yet by either issuing an > AUDIT_SIGNAL_INFO* request or the targetted audit daemon hadn't cleaned > up yet. EBUSY could be confused with already having spawned threads or > children, and ENOTUNIQ could indicate that another orchestrator/engine > had stolen its desired contid after we released it and wanted to reuse > it. All the more reason for ENOTUNIQ. The point is that the audit container ID is not available for use, and since the IDs are shared across the entire system I think we are better off having some ambiquity here with errnos. > This gets me thinking about making reservations for preferred > contids that are otherwise unavailable and making callbacks to indicate > when they become available, but that seems undesirably complex right > now. That is definitely beyond the scope of this work, or rather *should* be beyond the scope of this work. -- paul moore www.paul-moore.com