On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
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.
No, its a real thing just like a login. Does the kernel have any concept of a
login? Yet it happens. And it causes us to generate events describing who,
where from, role, success, and time of day. :-)
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.
I don't doubt that just as user space sequences the actions that are a login.
I just need the kernel to do some book keeping and associate the necessary
attributes in the event record to be able to reconstruct what is actually
happening.
-Steve
On May 15, 2015 9:38 PM, "Steve Grubb" [off-list ref] wrote:
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.
No, its a real thing just like a login. Does the kernel have any concept of a
login? Yet it happens. And it causes us to generate events describing who,
where from, role, success, and time of day. :-)
I really hope those records come from userspace, not the kernel. I
also wonder what happens when a user logs in and types "sudo agetty
/dev/ttyS0 115200". If a user does that and then someone logs in on
/dev/ttyS0, which login are they?
quoted
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.
I don't doubt that just as user space sequences the actions that are a login.
I just need the kernel to do some book keeping and associate the necessary
attributes in the event record to be able to reconstruct what is actually
happening.
A precondition for that is having those records have some
correspondence to what is actually happening. Since the kernel has no
concept of a container, and since the same kernel mechanisms could be
used for things that are probably not whatever the Common Criteria
rules think a container is, this could be quite difficult to define in
a meaningful manner.
Hence my suggestion to add only minimal support in the kernel and to
do this in userspace.
--Andy