Received: by 10.192.165.156 with SMTP id m28csp1609070imm; Wed, 18 Apr 2018 12:31:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+Dxcg/ZhMv6dc+ujdKvlzi7xbXFQT1hpau/KYNZsfTzJHwLcTjLSSflewC294o0PDp0l7f X-Received: by 2002:a17:902:683:: with SMTP id 3-v6mr3236286plh.206.1524079878171; Wed, 18 Apr 2018 12:31:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524079878; cv=none; d=google.com; s=arc-20160816; b=nzeNVQBbYlAIHr8d3+zw9GxqDTocb2IrDpHTzYDE8darsZrq9PSzo3seYtQoCQXULP r+cl3bXkakBiB4fhDjtPollJ/k5JbL6kCYi1js6iy8UPr5mgx/HIuBmyR1wQMMHwT/HX mKbUgX+Xv+nXqzByLj1vszWEwNYb2IkinWnukBqNRLIrcDmMZxYXJuKQVbVSyk/Qa2Dw 1qKKI1bOkd/5+qFqQ3pO8bfAD6vOWFANLk3SacoEDOnCzaVZl/22FeQ9syHP8Fca/9Xb nPHaP+IK5g7di2AviAUaNb6RGMlG8VjoXpvNxa5Fzx4OHIW6U0SR+7EMmFanQ2cGTB0K WX6w== 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:arc-authentication-results; bh=zqCLaRs0zazk9datJHXGiKAFaKHxW52ERW9PeInueLw=; b=eSkuxYUnAGdZydQEXbdfkSnrk6+KigmuIz8qlYv/BUsGIUTnwDK7RZ9JgwgcA2D79s XikVWzirm2gzx0HT15W8VIN79ajN13ajI/V6doSYFkQuo41fA7hk41CQfw273uY+xdek jXVAIYT9jlbeBt1Xf1vvjitsXvhLZL+Q2Q2lFitdl6pEe9L/GP4+CkHiZM0QEHGEBiTT VIlv68AQyxcfHR8zB4Omo1QJcH/R4l72KHlpwPhqdZrqA3laIs8JbuFJL9Prn89HAkI9 o89xomaGyPS7UlP59H7QGRCcSlZY0bxTH4MO1LECElBDft3HrqlOi3OQyC6vNqgBheoC M8TQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 t64si1610502pgc.160.2018.04.18.12.31.03; Wed, 18 Apr 2018 12:31:18 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752328AbeDRT36 (ORCPT + 99 others); Wed, 18 Apr 2018 15:29:58 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37002 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750872AbeDRT34 (ORCPT ); Wed, 18 Apr 2018 15:29:56 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 755D17B4A7; Wed, 18 Apr 2018 19:29:55 +0000 (UTC) Received: from madcap2.tricolour.ca (ovpn-112-12.rdu2.redhat.com [10.10.112.12]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BF93F2026DFD; Wed, 18 Apr 2018 19:29:51 +0000 (UTC) Date: Wed, 18 Apr 2018 15:23:59 -0400 From: Richard Guy Briggs To: Stefan Berger Cc: mszeredi@redhat.com, ebiederm@xmission.com, simo@redhat.com, jlayton@redhat.com, carlos@redhat.com, linux-api@vger.kernel.org, containers@lists.linux-foundation.org, LKML , eparis@parisplace.org, dhowells@redhat.com, Linux-Audit Mailing List , viro@zeniv.linux.org.uk, luto@kernel.org, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org, serge@hallyn.com, trondmy@primarydata.com Subject: Re: [RFC PATCH V1 01/12] audit: add container id Message-ID: <20180418192359.n4q53bvsdhrjftjg@madcap2.tricolour.ca> References: <2e5d93ee46feca915a101c2fc3062da674a98223.1519930146.git.rgb@redhat.com> <216d1ab1-531b-9185-2e31-34f162f08aad@linux.vnet.ibm.com> <20180316035837.ddnqvbyrbp3fdk7e@madcap2.tricolour.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171027 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 18 Apr 2018 19:29:55 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 18 Apr 2018 19:29:55 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'rgb@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-18 14:45, Stefan Berger wrote: > On 03/15/2018 11:58 PM, Richard Guy Briggs wrote: > > On 2018-03-15 16:27, Stefan Berger wrote: > > > On 03/01/2018 02:41 PM, Richard Guy Briggs wrote: > > > > Implement the proc fs write to set the audit container ID of a process, > > > > emitting an AUDIT_CONTAINER record to document the event. > > > > > > > > This is a write from the container orchestrator task to a proc entry of > > > > the form /proc/PID/containerid where PID is the process ID of the newly > > > > created task that is to become the first task in a container, or an > > > > additional task added to a container. > > > > > > > > The write expects up to a u64 value (unset: 18446744073709551615). > > > > > > > > This will produce a record such as this: > > > > type=UNKNOWN[1333] msg=audit(1519903238.968:261): op=set pid=596 uid=0 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 auid=0 tty=pts0 ses=1 opid=596 old-contid=18446744073709551615 contid=123455 res=0 > > > > > > > > The "op" field indicates an initial set. The "pid" to "ses" fields are > > > > the orchestrator while the "opid" field is the object's PID, the process > > > > being "contained". Old and new container ID values are given in the > > > > "contid" fields, while res indicates its success. > > > > > > > > It is not permitted to self-set, unset or re-set the container ID. A > > > > child inherits its parent's container ID, but then can be set only once > > > > after. > > > > > > > > See: https://github.com/linux-audit/audit-kernel/issues/32 > > > > > > > > > > > > /* audit_rule_data supports filter rules with both integer and string > > > > * fields. It corresponds with AUDIT_ADD_RULE, AUDIT_DEL_RULE and > > > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > > > > index 4e0a4ac..0ee1e59 100644 > > > > --- a/kernel/auditsc.c > > > > +++ b/kernel/auditsc.c > > > > @@ -2073,6 +2073,92 @@ int audit_set_loginuid(kuid_t loginuid) > > > > return rc; > > > > } > > > > > > > > +static int audit_set_containerid_perm(struct task_struct *task, u64 containerid) > > > > +{ > > > > + struct task_struct *parent; > > > > + u64 pcontainerid, ccontainerid; > > > > + pid_t ppid; > > > > + > > > > + /* Don't allow to set our own containerid */ > > > > + if (current == task) > > > > + return -EPERM; > > > > + /* Don't allow the containerid to be unset */ > > > > + if (!cid_valid(containerid)) > > > > + return -EINVAL; > > > > + /* if we don't have caps, reject */ > > > > + if (!capable(CAP_AUDIT_CONTROL)) > > > > + return -EPERM; > > > > + /* if containerid is unset, allow */ > > > > + if (!audit_containerid_set(task)) > > > > + return 0; > > > I am wondering whether there should be a check for the target process that > > > will receive the containerid to not have CAP_SYS_ADMIN that would otherwise > > > allow it to arbitrarily unshare()/clone() and leave the set of namespaces > > > that may make up the container whose containerid we assign here? > > This is a reasonable question. This has been debated and I understood > > the conclusion was that without a clear definition of a "container", the > > task still remains in that container that just now has more > > sub-namespaces (in the case of hierarchical namespaces), we don't want > > to restrict it in such a way and that allows it to create nested > > containers. I see setns being more problematic if it could switch to > > another existing namespace that was set up by the orchestrator for a > > different container. The coming v2 patchset acknowledges this situation > > with the network namespace being potentially shared by multiple > > containers. > > Are you going to post v2 soon? We would like to build on top of it for IMA > namespacing and auditing inside of IMA namespaces. I don't know if it addresses your specific needs, but V2 was posted on March 16th along with userspace patches: https://www.redhat.com/archives/linux-audit/2018-March/msg00110.html https://www.redhat.com/archives/linux-audit/2018-March/msg00124.html V3 is pending. > Stefan - 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