[PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon
sgrubb at redhat.com
Wed Feb 12 22:38:45 UTC 2020
On Wednesday, February 5, 2020 5:50:28 PM EST Paul Moore wrote:
> > > > > ... When we record the audit container ID in audit_signal_info() we
> > > > > take an extra reference to the audit container ID object so that it
> > > > > will not disappear (and get reused) until after we respond with an
> > > > > AUDIT_SIGNAL_INFO2. In audit_receive_msg() when we do the
> > > > > AUDIT_SIGNAL_INFO2 processing we drop the extra reference we took
> > > > > in
> > > > > audit_signal_info(). Unless I'm missing some other change you
> > > > > made,
> > > > > this *shouldn't* affect the syscall records, all it does is
> > > > > preserve
> > > > > the audit container ID object in the kernel's ACID store so it
> > > > > doesn't
> > > > > get reused.
> > > >
> > > > This is exactly what I had understood. I hadn't considered the extra
> > > > details below in detail due to my original syscall concern, but they
> > > > make sense.
> > > >
> > > > The syscall I refer to is the one connected with the drop of the
> > > > audit container identifier by the last process that was in that
> > > > container in patch 5/16. The production of this record is contingent
> > > > on
> > > > the last ref in a contobj being dropped. So if it is due to that ref
> > > > being maintained by audit_signal_info() until the AUDIT_SIGNAL_INFO2
> > > > record it fetched, then it will appear that the fetch action closed
> > > > the
> > > > container rather than the last process in the container to exit.
> > > >
> > > > Does this make sense?
> > >
> > > More so than your original reply, at least to me anyway.
> > >
> > > It makes sense that the audit container ID wouldn't be marked as
> > > "dead" since it would still be very much alive and available for use
> > > by the orchestrator, the question is if that is desirable or not. I
> > > think the answer to this comes down the preserving the correctness of
> > > the audit log.
> > >
> > > If the audit container ID reported by AUDIT_SIGNAL_INFO2 has been
> > > reused then I think there is a legitimate concern that the audit log
> > > is not correct, and could be misleading. If we solve that by grabbing
> > > an extra reference, then there could also be some confusion as
> > > userspace considers a container to be "dead" while the audit container
> > > ID still exists in the kernel, and the kernel generated audit
> > > container ID death record will not be generated until much later (and
> > > possibly be associated with a different event, but that could be
> > > solved by unassociating the container death record).
> > How does syscall association of the death record with AUDIT_SIGNAL_INFO2
> > possibly get associated with another event? Or is the syscall
> > association with the fetch for the AUDIT_SIGNAL_INFO2 the other event?
> The issue is when does the audit container ID "die". If it is when
> the last task in the container exits, then the death record will be
> associated when the task's exit. If the audit container ID lives on
> until the last reference of it in the audit logs, including the
> SIGNAL_INFO2 message, the death record will be associated with the
> related SIGNAL_INFO2 syscalls, or perhaps unassociated depending on
> the details of the syscalls/netlink.
> > Another idea might be to bump the refcount in audit_signal_info() but
> > mark tht contid as dead so it can't be reused if we are concerned that
> > the dead contid be reused?
> Ooof. Yes, maybe, but that would be ugly.
> > There is still the problem later that the reported contid is incomplete
> > compared to the rest of the contid reporting cycle wrt nesting since
> > AUDIT_SIGNAL_INFO2 will need to be more complex w/2 variable length
> > fields to accommodate a nested contid list.
> Do we really care about the full nested audit container ID list in the
> SIGNAL_INFO2 record?
> > > Of the two
> > > approaches, I think the latter is safer in that it preserves the
> > > correctness of the audit log, even though it could result in a delay
> > > of the container death record.
> > I prefer the former since it strongly indicates last task in the
> > container. The AUDIT_SIGNAL_INFO2 msg has the pid and other subject
> > attributes and the contid to strongly link the responsible party.
> Steve is the only one who really tracks the security certifications
> that are relevant to audit, see what the certification requirements
> have to say and we can revisit this.
Sever Virtualization Protection Profile is the closest applicable standard
It is silent on audit requirements for the lifecycle of a VM. I assume that
all that is needed is what the orchestrator says its doing at the high level.
So, if an orchestrator wants to shutdown a container, the orchestrator must
log that intent and its results. In a similar fashion, systemd logs that it's
killing a service and we don't actually hook the exit syscall of the service
to record that.
Now, if a container was being used as a VPS, and it had a fully functioning
userspace, it's own services, and its very own audit daemon, then in this
case it would care who sent a signal to its auditd. The tenant of that
container may have to comply with PCI-DSS or something else. It would log the
audit service is being terminated and systemd would record that its tearing
down the environment. The OS doesn't need to do anything.
More information about the Containers