On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
[off-list ref] wrote:
Paul Moore [off-list ref] writes:
quoted
On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh [off-list ref] wrote:
quoted
On 05/15/2015 05:05 PM, Paul Moore wrote:
quoted
On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
quoted
On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs [off-list ref] wrote:
quoted
On 15/05/14, Paul Moore wrote:
quoted
* 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
On 15/05/16, Paul Moore wrote:
On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman
[off-list ref] wrote:
quoted
Paul Moore [off-list ref] writes:
quoted
On Sat, May 16, 2015 at 5:46 AM, Daniel J Walsh [off-list ref] wrote:
quoted
On 05/15/2015 05:05 PM, Paul Moore wrote:
quoted
On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
quoted
On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs [off-list ref] wrote:
quoted
On 15/05/14, Paul Moore wrote:
quoted
* 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.
quoted
From an auditing perspective I'm not sure we will ever hit those
cases; did you have a particular example in mind?
The example that immediately came to mind when I first read Eric's
comment was a packet coming in off a network in a particular network
namespace. That could narrow it down to a subset of containers based on
which network namespace it inhabits, but since it isn't associated with
a particular task yet (other than a kernel thread) it will not be
possible to select the precise nsproxy, let alone the container.
paul moore
- RGB
--
Richard Guy Briggs [off-list ref]
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
On Tue, May 19, 2015 at 9:09 AM, Richard Guy Briggs [off-list ref] wrote:
On 15/05/16, Paul Moore wrote:
quoted
On Sat, May 16, 2015 at 10:46 AM, Eric W. Biederman wrote:
quoted
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?
The example that immediately came to mind when I first read Eric's
comment was a packet coming in off a network in a particular network
namespace. That could narrow it down to a subset of containers based on
which network namespace it inhabits, but since it isn't associated with
a particular task yet (other than a kernel thread) it will not be
possible to select the precise nsproxy, let alone the container.
Thanks, I was stuck thinking about syscall based auditing and forgot
about the various LSM based audit records. Of all people you would
think I would remember per-packet audit records ;)
Anyway, in this case I think including the namespace ID is sufficient,
largely because the container userspace doesn't have access to the
packet at this point. In order to actually receive the data the
container's userspace will need to issue a syscall where we can
include the container ID. An overly zealous security officer who
wants to trace all the kernel level audit events, like the one you
describe, can match up the namespace to a container in post-processing
if needed.
--
paul moore
www.paul-moore.com