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:	Tue, 06 May 2014 14:35:03 +0200
From:	Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>
CC:	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com,
	ebiederm@...ssion.com
Subject: Re: [PATCH 0/2] namespaces: log namespaces per task

Le 06/05/2014 01:23, James Bottomley a écrit :
>
>
> On May 5, 2014 3:36:38 PM PDT, Serge Hallyn <serge.hallyn@...ntu.com> wrote:
>> Quoting James Bottomley (James.Bottomley@...senPartnership.com):
>>> On Mon, 2014-05-05 at 22:27 +0000, Serge Hallyn wrote:
>>>> Quoting James Bottomley (James.Bottomley@...senPartnership.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@...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.
>>>>
>>>> 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
--
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/