From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Schaufler Subject: Re: RFC(v2): Audit Kernel Container IDs Date: Thu, 12 Oct 2017 09:33:49 -0700 Message-ID: <75b7d6a6-42ba-2dff-1836-1091c7c024e7@schaufler-ca.com> References: <20171012141359.saqdtnodwmbz33b2@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1507826034; bh=j/4oqVu02pC8j5MrXEVZDV2Elqng2RWh4jxyQLLUQwY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=FYOwhzQmB+4JAxsUWQCsVziQbiZohzi/rFoR1nm/EuJ9fM+BBrO0hEkcE/k5lUWLY8d+tCqpEhoXDS53qhpU6ESudCkr5rRTk/CxAvUvZP20vrHLGVoKB7Q1ma3edeXqKR+/vr2Aj8J6HA4Q8P3ejKh7QaprWqFuJgiX6ZUkftdLvExwGFkN++sVgcKySkzsLMF62Zsx5LpYCAWepyCpKESUc8LheWbXx95TRV1h7ogHJfiKifgLZ5wTRcAKvOgqBI4/Gl8rp04zc4PkdkGxBHQrApolMWh7h+yL1ualDwtvevhZtlIa/15izXvGvmGTP9hHXgVxUs4Tp4XL4zsgBg== In-Reply-To: <20171012141359.saqdtnodwmbz33b2-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org> Content-Language: en-US Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Richard Guy Briggs , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers , Linux API , Linux Audit , Linux FS Devel , Linux Kernel , Linux Network Development Cc: mszeredi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Andy Lutomirski , jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Carlos O'Donell , Al Viro , David Howells , Simo Sorce , trondmy-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org, Eric Paris , "Serge E. Hallyn" , "Eric W. Biederman" On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > Containers are a userspace concept. The kernel knows nothing of them. > > The Linux audit system needs a way to be able to track the container > provenance of events and actions. Audit needs the kernel's help to do > this. > > Since the concept of a container is entirely a userspace concept, a > registration from the userspace container orchestration system initiates > this. This will define a point in time and a set of resources > associated with a particular container with an audit container ID. > > The registration is a pseudo filesystem (proc, since PID tree already > exists) write of a u8[16] UUID representing the container ID to a file > representing a process that will become the first process in a new > container. This write might place restrictions on mount namespaces > required to define a container, or at least careful checking of > namespaces in the kernel to verify permissions of the orchestrator so it > can't change its own container ID. A bind mount of nsfs may be > necessary in the container orchestrator's mntNS. > Note: Use a 128-bit scalar rather than a string to make compares faster > and simpler. > > Require a new CAP_CONTAINER_ADMIN to be able to carry out the > registration. Hang on. If containers are a user space concept, how can you want CAP_CONTAINER_ANYTHING? If there's not such thing as a container, how can you be asking for a capability to manage them? > At that time, record the target container's user-supplied > container identifier along with the target container's first process > (which may become the target container's "init" process) process ID > (referenced from the initial PID namespace), all namespace IDs (in the > form of a nsfs device number and inode number tuple) in a new auxilliary > record AUDIT_CONTAINER with a qualifying op=$action field. > > Issue a new auxilliary record AUDIT_CONTAINER_INFO for each valid > container ID present on an auditable action or event. > > Forked and cloned processes inherit their parent's container ID, > referenced in the process' task_struct. > > Mimic setns(2) and return an error if the process has already initiated > threading or forked since this registration should happen before the > process execution is started by the orchestrator and hence should not > yet have any threads or children. If this is deemed overly restrictive, > switch all threads and children to the new containerID. > > Trust the orchestrator to judiciously use and restrict CAP_CONTAINER_ADMIN. > > Log the creation of every namespace, inheriting/adding its spawning > process' containerID(s), if applicable. Include the spawning and > spawned namespace IDs (device and inode number tuples). > [AUDIT_NS_CREATE, AUDIT_NS_DESTROY] [clone(2), unshare(2), setns(2)] > Note: At this point it appears only network namespaces may need to track > container IDs apart from processes since incoming packets may cause an > auditable event before being associated with a process. > > Log the destruction of every namespace when it is no longer used by any > process, include the namespace IDs (device and inode number tuples). > [AUDIT_NS_DESTROY] [process exit, unshare(2), setns(2)] > > Issue a new auxilliary record AUDIT_NS_CHANGE listing (opt: op=$action) > the parent and child namespace IDs for any changes to a process' > namespaces. [setns(2)] > Note: It may be possible to combine AUDIT_NS_* record formats and > distinguish them with an op=$action field depending on the fields > required for each message type. > > When a container ceases to exist because the last process in that > container has exited and hence the last namespace has been destroyed and > its refcount dropping to zero, log the fact. > (This latter is likely needed for certification accountability.) A > container object may need a list of processes and/or namespaces. > > A namespace cannot directly migrate from one container to another but > could be assigned to a newly spawned container. A namespace can be > moved from one container to another indirectly by having that namespace > used in a second process in another container and then ending all the > processes in the first container. > > (v2) > - switch from u64 to u128 UUID > - switch from "signal" and "trigger" to "register" > - restrict registration to single process or force all threads and children into same container > > - 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 > > -- > Linux-audit mailing list > Linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org > https://www.redhat.com/mailman/listinfo/linux-audit >