lkml.org 
[lkml]   [2020]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH ghak90 V8 07/16] audit: add contid support for signalling the audit daemon
Date
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

https://www.niap-ccevs.org/Profile/Info.cfm?PPID=408&id=408

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.

-Steve


\
 
 \ /
  Last update: 2020-02-12 23:39    [W:0.148 / U:1.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site