netdev - Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

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:	Sat, 16 May 2015 05:46:34 -0400
From:	Daniel J Walsh <dwalsh@...hat.com>
To:	Paul Moore <pmoore@...hat.com>,
	Andy Lutomirski <luto@...capital.net>
CC:	"Serge E. Hallyn" <serge@...lyn.com>,
	Richard Guy Briggs <rgb@...hat.com>,
	Linux API <linux-api@...r.kernel.org>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>, linux-audit@...hat.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Network Development <netdev@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Eric Paris <eparis@...isplace.org>
Subject: Re: [PATCH V6 05/10] audit: log creation and deletion of namespace
 instances



On 05/15/2015 05:05 PM, Paul Moore wrote:
> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
>> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb@...hat.com> wrote:
>>> On 15/05/14, Paul Moore wrote:
>>>> * Look at our existing audit records to determine which records should
>>>> have
>>>> namespace and container ID tokens added.  We may only want to add the
>>>> additional fields in the case where the namespace/container ID tokens are
>>>> not the init namespace.
>>> If we have a record that ties a set of namespace IDs with a container
>>> ID, then I expect we only need to list the containerID along with auid
>>> and sessionID.
>> The problem here is that the kernel has no concept of a "container", and I
>> don't think it makes any sense to add one just for audit.  "Container" is a
>> marketing term used by some userspace tools.
>>
>> I can imagine that both audit could benefit from a concept of a
>> namespace *path* that understands nesting (e.g. root/2/5/1 or
>> something along those lines).  Mapping these to "containers" belongs
>> in userspace, I think.
> It might be helpful to climb up a few levels in this thread ...
>
> I think we all agree that containers are not a kernel construct.  I further 
> believe that the kernel has no business generating container IDs, those should 
> come from userspace and will likely be different depending on how you define 
> "container".  However, what is less clear to me at this point is how the 
> kernel should handle the setting, reporting, and general management of this 
> container ID token.
>
Wouldn't the easiest thing be to just treat add a containerid to the
process context like auid.  Then
make it a privileged operation to set it.  Then tools that care about
auditing like docker can set the ID
and remove the Capability from it sub processes if it cares.  All
processes adopt parent processes containerid.
Now containers can be audited and as long as userspace is written
correctly nested containers can either override the containerid or not
depending on what the audit rules are.

No special handling inside of namespaces.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html