linux-kernel - Re: [PATCH 0/2] namespaces: log namespaces per task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 May 2014 18:11:48 -0400
From:	Richard Guy Briggs <rgb@...hat.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, serge.hallyn@...ntu.com,
	eparis@...hat.com, sgrubb@...hat.com, ebiederm@...ssion.com
Subject: Re: [PATCH 0/2] namespaces: log namespaces per task

On 14/05/05, James Bottomley wrote:
> 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@...senPartnership.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=%x,new_serial=%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.

If a container was defined as an entity with 6 namespaces to itself,
this would make sense.  As Eric P. put it, containers/namespaces seem to
be a bucket of semi-related nuts and bolts, with any namespace being
optional depending on the application.  My understanding is a
container could be migrated to another host requiring the creation of
(none,) some or all of its namespaces, potentially leaving behind some
of its shared namespaces and/or clashing names of namespaces on the
destination host.

> James
> 
> > > -serge
> > > 
> > > (Another, more heavyweight approach would be to track all ns hierarchies
> > > and make the serial numbers per-namespace-instance.  So my container's
> > > pidns serial might be 0x2, and if it clones a new pidns that would be
> > > "(0x2,0x1)" on the host, or just 0x1 inside the container.  But we don't
> > > need that if the simple userspace approach suffices)
> > 
> > This sounds manageable...
> > 
> > - RGB
> > 
> > --
> > Richard Guy Briggs <rbriggs@...hat.com>
> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> > Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> 
> 
> 

- RGB

--
Richard Guy Briggs <rbriggs@...hat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/