All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: linux-audit@redhat.com
Cc: Wajih Ul Hassan <wajih.lums@gmail.com>
Subject: Re: Separating Container(docker) Logs
Date: Sat, 11 Mar 2017 13:31:15 -0500	[thread overview]
Message-ID: <11460342.biKctF48Sg@x2> (raw)
In-Reply-To: <CAH5sRbpehx9hTbnMY7=8huGReC_OAN9Z-QJRzfbj17uTU6sUiQ@mail.gmail.com>

On Friday, March 10, 2017 11:47:06 PM EST Wajih Ul Hassan wrote:
> I have been using Linux Audit Module for a while now especially in the
> context of container(docker) environment. I use SELinux MCS labels with
> docker --selinux-enabled to separate different container logs in auditd log
> stream. But this solution is very limited to SELinux enabled OS and cannot
> be ported to other systems like Ubuntu which uses AppArmour. So I am
> looking for some other way to separate each container logs in auditd log
> stream. If somebody can give me pointers or patches that makes
> auditd container aware it will be really helpful for me.

This is slowly being pulled together. This has to be done with common criteria 
(CC) certifications in mind since pci-dss, STIG, various contracting language 
all call out for or assume a common criteria certification. The first step in 
this direction was in pulling together a specification for container management 
events based on the virtualization protection profile.

https://github.com/linux-audit/audit-documentation/wiki/SPEC-Virtualization-Manager-Guest-Lifecycle-Events

The next step is to define what a container is and the use cases. From that we 
can advance the specification for auditing as it relates to containers. We will 
be digging into this soon. We can't really press forward without understanding 
all the certification requirements and this may even take some committee work 
to iron out the CC requirements. I'd hate to do something and then find out it 
doesn't meet requirements and undo and redo how it works. That would be too 
much disruption for utilities that might process the information.

So, I think the answer for right now is you have to use labels. But this will 
get addressed in the coming months.

-Steve

      reply	other threads:[~2017-03-11 18:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-11  4:47 Separating Container(docker) Logs Wajih Ul Hassan
2017-03-11 18:31 ` Steve Grubb [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11460342.biKctF48Sg@x2 \
    --to=sgrubb@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=wajih.lums@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.