From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Dichtel Subject: Re: [PATCH 0/2] namespaces: log namespaces per task Date: Tue, 06 May 2014 14:35:03 +0200 Message-ID: <5368D6F7.3030200@6wind.com> References: <1399154328.2505.29.camel@dabdike.int.hansenpartnership.com> <20140505034814.GA27548@mail.hallyn.com> <20140505214818.GC6867@madcap2.tricolour.ca> <1399326698.2164.47.camel@dabdike.int.hansenpartnership.com> <20140505222758.GA6508@ubuntumail> <1399329001.2164.56.camel@dabdike.int.hansenpartnership.com> <20140505223638.GB6508@ubuntumail> Reply-To: nicolas.dichtel@6wind.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mx1.redhat.com (ext-mx11.extmail.prod.ext.phx2.redhat.com [10.5.110.16]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s46CZ8Sb003519 for ; Tue, 6 May 2014 08:35:10 -0400 Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s46CZ5E9018301 for ; Tue, 6 May 2014 08:35:06 -0400 Received: by mail-we0-f170.google.com with SMTP id u57so2421209wes.1 for ; Tue, 06 May 2014 05:35:05 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: James Bottomley , Serge Hallyn Cc: containers@lists.linux-foundation.org, linux-audit@redhat.com, linux-kernel@vger.kernel.org, ebiederm@xmission.com List-Id: linux-audit@redhat.com Le 06/05/2014 01:23, James Bottomley a =E9crit : > > > On May 5, 2014 3:36:38 PM PDT, Serge Hallyn wro= te: >> Quoting James Bottomley (James.Bottomley@HansenPartnership.com): >>> On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote: >>>> Quoting James Bottomley (James.Bottomley@HansenPartnership.com): >>>>> On Mon, 2014-05-05 at 17:48 -0400, Richard Guy Briggs wrote: >>>>>> On 14/05/05, Serge E. Hallyn wrote: >>>>>>> Quoting James Bottomley >> (James.Bottomley@HansenPartnership.com): >>>>>>>> On Tue, 2014-04-22 at 14:12 -0400, Richard Guy Briggs >> wrote: >>>>>>>>> Questions: >>>>>>>>> Is there a way to link serial numbers of namespaces >> involved in migration of a >>>>>>>>> container to another kernel? (I had a brief look at >> CRIU.) Is there a unique >>>>>>>>> identifier for each running instance of a kernel? Or at >> least some identifier >>>>>>>>> within the container migration realm? >>>>>>>> >>>>>>>> Are you asking for a way of distinguishing an migrated >> container from an >>>>>>>> unmigrated one? The answer is pretty much "no" because the >> job of >>>>>>>> migration is to restore to the same state as much as >> possible. >>>>>>>> >>>>>>>> Reading between the lines, I think your goal is to >> correlate audit >>>>>>>> information across a container migration, right? Ideally >> the management >>>>>>>> system should be able to cough up an audit trail for a >> container >>>>>>>> wherever it's running and however many times it's been >> migrated? >>>>>>>> >>>>>>>> In that case, I think your idea of a numeric serial number >> in a dense >>>>>>>> range is wrong. Because the range is dense you're >> obviously never going >>>>>>>> to be able to use the same serial number across a >> migration. However, >>>>>>> >>>>>>> Ah, but I was being silly before, we can actually address >> this pretty >>>>>>> simply. If we just (for instance) add >>>>>>> /proc/self/ns/{ic,mnt,net,pid,user,uts}_seq containing the >> serial number >>>>>>> for the relevant ns for the task, then criu can dump this >> info at >>>>>>> checkpoint. Then at restart it can dump an audit message per >> task and >>>>>>> ns saying old_serial=3D%x,new_serial=3D%x. That way the audit >> log reader >>>>>>> can if it cares keep track. >>>>>> >>>>>> This is the sort of idea I had in mind... >>>>> >>>>> OK, but I don't understand then why you need a serial number. >> There are >>>>> plenty of things we preserve across a migration, like namespace >> name for >>>>> instance. Could you explain what function it performs because I >> think I >>>>> might be missing something. >>>> >>>> We're looking ahead to a time when audit is namespaced, and a >> container >>>> can keep its own audit logs (without limiting what the host audits >> of >>>> course). So if a container is auditing suspicious activity by some >>>> task in a sub-namesapce, then the whole parent container gets >> migrated, >>>> after migration we want to continue being able to correlate the >> namespaces. >>>> >>>> We're also looking at audit trails on a host that is up for years. >> We >>>> would like every namespace to be uniquely logged there. That is >> why >>>> inode #s on /proc/self/ns/* are not sufficient, unless we add a >> generation >>>> # (which would end more complicated, not less, than a serial #). >>> >>> Right, but when the contaner has an audit namespace, that namespace >> has >>> a name, >> >> What ns has a name? > > The netns for instance. netns does not have names. iproute2 uses names (a filename in fact, to hold= a reference on the netns), but the kernel never got this name. It only get a = file descriptor (or a pid). Regards, Nicolas