On 15/05/14, Oren Laadan wrote:
On Thu, May 14, 2015 at 8:48 PM, Richard Guy Briggs
<rgb(a)redhat.com> 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.
I assume it would be a bit more than that, including cgroup and seccomp info.
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).
I'd be fine with either, even including the nsfs deviceID.
Oren.
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545