Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1092906ybl; Thu, 23 Jan 2020 13:26:47 -0800 (PST) X-Google-Smtp-Source: APXvYqzDQXhXOsJF/AmWBFC/XQD5I67vRXCvTa9ZP0Xtxa5+ON2dtZTK8Qf5OdBOfSE3+LaX6ZW1 X-Received: by 2002:aca:1c1a:: with SMTP id c26mr12094996oic.75.1579814807348; Thu, 23 Jan 2020 13:26:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579814807; cv=none; d=google.com; s=arc-20160816; b=GtFg2prceo4Rfqti7CGlU4+0Ipr2mkE2eBQb0LbYlJI9+NljFnxp8dao1B3HylkNK+ Lj2aV6w40rEqid/5jdP2PAzfNGdq6DnTbn427rgxikaXbcIzA2ZMe5u+EUzjtU9WTUV8 eoBbZbRnLxDzZovOdjkvRdd9dAbswkSyc2e7rdwUnkBrraGdZdY4xodw7+kQUFaG0K7P plOh9/Z+Rsq0YBP3vjiRqPrtRIztXMVKiTFqUPY88S7wItcaQc7VRkqnHJOTHv9Zlj/a jNP/nK3ECNQ0qLcvCptrd0x9uJw6CJCMuVBnEx40tUqvA3WNEsquDSDj+WosU9ViUIRn 46vg== 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=YZjD8aqaGH6JNDHX+A7tsAQo+cl/H8KbJHBmNjl1CAs=; b=aBYznDv7EQP+efiRii3JX7XTay5iDZOUAwXXC2GLC+UkdLhmnhcPkNtbhjTaGKwhsO 2pR5QIkbIVvi8n+Wnj0FEjGY+Oxoc6wS7z0b62LpyO5lAiM2VEeiJSspMBwxoEYKh6hc cF6ldiOBr7VsrQLqf1cBpjbqpI2nQ1KbfVHiWyEEFjIwCavCCbMaO3MKG73k4hu1Lt7V dAcji3Gbf8ThcPVqplv8oLTczcxJJO+d8bGfvAa5fxaW2Htb0DCZLuNFwn0HDLPqReC8 SrDvPk/n11VIx/+CJrvCBSG1ziFJnkWRqi7fH8GgfROWqiIKuVNIucqeSzUqfAE/0kS1 lodQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AL+8uFF+; 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 s5si1378677oic.116.2020.01.23.13.26.35; Thu, 23 Jan 2020 13:26:47 -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=AL+8uFF+; 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 S1729387AbgAWVDD (ORCPT + 99 others); Thu, 23 Jan 2020 16:03:03 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:57869 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726191AbgAWVDC (ORCPT ); Thu, 23 Jan 2020 16:03:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579813381; 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=YZjD8aqaGH6JNDHX+A7tsAQo+cl/H8KbJHBmNjl1CAs=; b=AL+8uFF+N9owvQ37LFmYwnD7fBbJkvTjCFZFoMX63i47bouTzEgAQ/diB80WmxGLXY12Fl sjLXqcCJj+VwaYqRaWdnFSaH+BhrWxxjlCjBDhHV64H5C3naOTRfjmU+N1OHh0WI4FzepD 5nmDerGdr/RS3oxceCs0UG+/D5ATX3M= 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-312-HDmQ2MhAMA6cXpt_V3B92g-1; Thu, 23 Jan 2020 16:02:57 -0500 X-MC-Unique: HDmQ2MhAMA6cXpt_V3B92g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D398B8024E5; Thu, 23 Jan 2020 21:02:54 +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 467D281207; Thu, 23 Jan 2020 21:02:43 +0000 (UTC) Date: Thu, 23 Jan 2020 16:02:40 -0500 From: Richard Guy Briggs To: Paul Moore 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 Subject: Re: [PATCH ghak90 V8 12/16] audit: contid check descendancy and nesting Message-ID: <20200123210240.sq64tptjm3ds7xss@madcap2.tricolour.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-01-22 16:29, Paul Moore wrote: > On Tue, Dec 31, 2019 at 2:51 PM Richard Guy Briggs wrote: > > > > Require the target task to be a descendant of the container > > orchestrator/engine. > > > > You would only change the audit container ID from one set or inherited > > value to another if you were nesting containers. > > > > If changing the contid, the container orchestrator/engine must be a > > descendant and not same orchestrator as the one that set it so it is not > > possible to change the contid of another orchestrator's container. > > > > Since the task_is_descendant() function is used in YAMA and in audit, > > remove the duplication and pull the function into kernel/core/sched.c > > > > Signed-off-by: Richard Guy Briggs > > --- > > include/linux/sched.h | 3 +++ > > kernel/audit.c | 44 ++++++++++++++++++++++++++++++++++++-------- > > kernel/sched/core.c | 33 +++++++++++++++++++++++++++++++++ > > security/yama/yama_lsm.c | 33 --------------------------------- > > 4 files changed, 72 insertions(+), 41 deletions(-) > > ... > > > diff --git a/kernel/audit.c b/kernel/audit.c > > index f7a8d3288ca0..ef8e07524c46 100644 > > --- a/kernel/audit.c > > +++ b/kernel/audit.c > > @@ -2603,22 +2610,43 @@ int audit_set_contid(struct task_struct *task, u64 contid) > > oldcontid = audit_get_contid(task); > > read_lock(&tasklist_lock); > > /* Don't allow the contid to be unset */ > > - if (!audit_contid_valid(contid)) > > + if (!audit_contid_valid(contid)) { > > rc = -EINVAL; > > + goto unlock; > > + } > > /* Don't allow the contid to be set to the same value again */ > > - else if (contid == oldcontid) { > > + if (contid == oldcontid) { > > rc = -EADDRINUSE; > > + goto unlock; > > + } > > /* if we don't have caps, reject */ > > - else if (!capable(CAP_AUDIT_CONTROL)) > > + if (!capable(CAP_AUDIT_CONTROL)) { > > rc = -EPERM; > > - /* if task has children or is not single-threaded, deny */ > > - else if (!list_empty(&task->children)) > > + goto unlock; > > + } > > + /* if task has children, deny */ > > + if (!list_empty(&task->children)) { > > rc = -EBUSY; > > - else if (!(thread_group_leader(task) && thread_group_empty(task))) > > + goto unlock; > > + } > > + /* if task is not single-threaded, deny */ > > + if (!(thread_group_leader(task) && thread_group_empty(task))) { > > rc = -EALREADY; > > - /* if contid is already set, deny */ > > - else if (audit_contid_set(task)) > > + goto unlock; > > + } > > It seems like the if/else-if conversion above should be part of an > earlier patchset. I had considered that, but it wasn't obvious where that conversion should happen since it wasn't necessary earlier and is now. I can move it earlier if you feel strongly about it. > > + /* if task is not descendant, block */ > > + if (task == current) { > > + rc = -EBADSLT; > > + goto unlock; > > + } > > + if (!task_is_descendant(current, task)) { > > + rc = -EXDEV; > > + goto unlock; > > + } > > I understand you are trying to provide a unique error code for each > failure case, but this is getting silly. Let's group the descendent > checks under the same error code. Ok. I was trying to provide more information for debugging for me and for users. > > + /* only allow contid setting again if nesting */ > > + if (audit_contid_set(task) && audit_contid_isowner(task)) > > rc = -ECHILD; > > Should that be "!audit_contid_isowner()"? No. If the contid is already set on this task and if it is the same orchestrator that already owns this one, then block it since the same orchestrator is not allowed to set it again. Another orchestrator that has been shown by previous tests to be a descendant of the orchestrator that already owns this one would be permitted. Now that I say this explicitly, it appears I need another test to check: /* only allow contid setting again if nesting */ if (audit_contid_set(task) && ( audit_contid_isowner(task) || !task_is_descendant(_audit_contobj(task)->owner, current) )) rc = -ECHILD; So we're back to audit_contobj_owner() like in the previous patchset that would make this cleaner. > 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