On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman <ebied...@xmission.com> wrote: > Paul Moore <p...@paul-moore.com> writes: >> On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh <dwa...@redhat.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 <r...@redhat.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 linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
