On 2020-03-18 18:06, Paul Moore wrote:

On Wed, Mar 18, 2020 at 5:56 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-18 17:42, Paul Moore wrote:

quoted

On Wed, Mar 18, 2020 at 5:27 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-18 16:56, Paul Moore wrote:

quoted

On Fri, Mar 13, 2020 at 2:59 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-03-13 12:29, Paul Moore wrote:

quoted

On Thu, Mar 12, 2020 at 3:30 PM Richard Guy Briggs [off-list ref] wrote:

quoted

On 2020-02-13 16:44, Paul Moore wrote:

quoted

This is a bit of a thread-hijack, and for that I apologize, but
another thought crossed my mind while thinking about this issue
further ... Once we support multiple auditd instances, including the
necessary record routing and duplication/multiple-sends (the host
always sees *everything*), we will likely need to find a way to "trim"
the audit container ID (ACID) lists we send in the records.  The
auditd instance running on the host/initns will always see everything,
so it will want the full container ACID list; however an auditd
instance running inside a container really should only see the ACIDs
of any child containers.

Agreed.  This should be easy to check and limit, preventing an auditd
from seeing any contid that is a parent of its own contid.

quoted

For example, imagine a system where the host has containers 1 and 2,
each running an auditd instance.  Inside container 1 there are
containers A and B.  Inside container 2 there are containers Y and Z.
If an audit event is generated in container Z, I would expect the
host's auditd to see a ACID list of "1,Z" but container 1's auditd
should only see an ACID list of "Z".  The auditd running in container
2 should not see the record at all (that will be relatively
straightforward).  Does that make sense?  Do we have the record
formats properly designed to handle this without too much problem (I'm
not entirely sure we do)?

I completely agree and I believe we have record formats that are able to
handle this already.

I'm not convinced we do.  What about the cases where we have a field
with a list of audit container IDs?  How do we handle that?

I don't understand the problem.  (I think you crossed your 1/2 vs
A/B/Y/Z in your example.) ...

It looks like I did, sorry about that.

quoted

... Clarifying the example above, if as you
suggest an event happens in container Z, the hosts's auditd would report
        Z,^2
and the auditd in container 2 would report
        Z,^2
but if there were another auditd running in container Z it would report
        Z
while the auditd in container 1 or A/B would see nothing.

Yes.  My concern is how do we handle this to minimize duplicating and
rewriting the records?  It isn't so much about the format, although
the format is a side effect.

Are you talking about caching, or about divulging more information than
necessary or even information leaks?  Or even noticing that records that
need to be generated to two audit daemons share the same contid field
values and should be generated at the same time or information shared
between them?  I'd see any of these as optimizations that don't affect
the api.

Imagine a record is generated in a container which has more than one
auditd in it's ancestry that should receive this record, how do we
handle that without completely killing performance?  That's my
concern.  If you've already thought up a plan for this - excellent,
please share :)

No, I haven't given that much thought other than the correctness and
security issues of making sure that each audit daemon is sufficiently
isolated to do its job but not jeopardize another audit domain.  Audit
already kills performance, according to some...

We currently won't have that problem since there can only be one so far.
Fixing and optimizing this is part of the next phase of the challenge of
adding a second audit daemon.

Let's work on correctness and reasonable efficiency for this phase and
not focus on a problem we don't yet have.  I wouldn't consider this
incurring technical debt at this point.

I agree, one stage at a time, but the choice we make here is going to
have a significant impact on what we can do later.  We need to get
this as "right" as possible; this isn't something we should dismiss
with a hand-wave as a problem for the next stage.  We don't need an
implementation, but I would like to see a rough design of how we would
address this problem.

quoted

I could see cacheing a contid string from one starting point, but it may
be more work to search that cached string to truncate it or add to it
when another audit daemon requests a copy of a similar string.  I
suppose every full contid string could be generated the first time it is
used and parts of it used (start/finish) as needed but that
search/indexing may not be worth it.

I hope we can do better than string manipulations in the kernel.  I'd
much rather defer generating the ACID list (if possible), than
generating a list only to keep copying and editing it as the record is
sent.

At the moment we are stuck with a string-only format.  The contid list
only exists in the kernel.  When do you suggest generating the contid
list?  It sounds like you are hinting at userspace generating that list
from multiple records over the span of audit logs since boot of the
machine.

Even if we had a binary format, the current design would require
generating that list at the time of record generation since it could be
any contiguous subset of a full nested contid list.

paul moore

- RGB

--
Richard Guy Briggs [off-list ref]
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635