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]

Message-ID: <CAHC9VhQs6pxFC3dvZic5XzuJr1xdJZyPjXdBoipwY3OOkng0ng@mail.gmail.com>
Date:	Sat, 16 May 2015 18:49:39 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Daniel J Walsh <dwalsh@...hat.com>, Paul Moore <pmoore@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	"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,
	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 Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Paul Moore <paul@...l-moore.com> writes:
>> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwalsh@...hat.com> wrote:
>>> 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.
>>
>> I believe so.  At least that was the point I was trying to get across
>> when I first jumped into this thread.
>
> It sounds nice but containers are not just a per process construct.
> Sometimes you might know anamespace but not which process instigated
> action to happen on that namespace.

>From an auditing perspective I'm not sure we will ever hit those
cases; did you have a particular example in mind?

-- 
paul moore
www.paul-moore.com
--
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