Thread (3 messages) 3 messages, 3 authors, 2015-05-19

Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances

From: Paul Moore <paul@paul-moore.com>
Date: 2015-05-19 14:27:35
Also in: linux-api, linux-fsdevel, lkml

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help