On Thu, May 14, 2015 at 8:48 PM, Richard Guy Briggs <rgb@xxxxxxxxxx> wrote:
>
> > > > Recording each instance of a name space is giving me something that I
> > > > cannot use to do queries required by the security target. Given these
> > > > events, how do I locate a web server event where it accesses a
> watched
> > > > file? That authentication failed? That an update within the container
> > > > failed?
> > > >
> > > > The requirements are that we have to log the creation, suspension,
> > > > migration, and termination of a container. The requirements are not
> on
> > > > the individual name space.
> > >
> > > Ok. Do we have a robust definition of a container?
> >
> > We call the combination of name spaces, cgroups, and seccomp rules a
> > container.
>
> Can you detail what information is required from each?
>
> > > Where is that definition managed?
> >
> > In the thing that invokes a container.
>
> I was looking for a reference to a standards document rather than an
> application...
>
>
[focusing on "containers id" - snipped the rest away]
I am unfamiliar with the audit subsystem, but work with namespaces in other
contexts. Perhaps the term "container" is overloaded here. The definition
suggested by Steve in this thread makes sense to me: "a combination of
namespaces". I imagine people may want to audit subsets of namespaces.
For namespaces, can use a string like "A:B:C:D:E:F" as an identifier for a
particular combination, where A-F are respective namespaces identifiers.
(Can be taken for example from /proc/PID/ns/{mnt,uts,ipc,user,pid,net}).
That will even be grep-able to locate records related to a particular
subset
of namespaces. So a "container" in the classic meaning would have all A-F
unique and different from the init process, but processes separated only by
e.g. mnt-ns and net-ns will differ from the init process in A and F.
(If a string is a no go, then perhaps combine the IDs in a unique way into a
super ID).
Oren.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
