On 10/17/2017 5:31 AM, Simo Sorce wrote:

On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote:

quoted

On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote:

quoted

There is such a thing, but the kernel doesn't know about it
yet.  This same situation exists for loginuid and sessionid which
are userspace concepts that the kernel tracks for the convenience
of userspace.  As for its name, I'm not particularly picky, so if
you don't like CAP_CONTAINER_* then I'm fine with
CAP_AUDIT_CONTAINERID.  It really needs to be distinct from
CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL since we don't want to give
the ability to set a containerID to any process that is able to do
audit logging (such as vsftpd) and similarly we don't want to give
the orchestrator the ability to control the setup of the audit
daemon.

A long time ago, we were debating what should guard against rouge
processes from setting the loginuid. Casey argued that the ability to
set the loginuid means they have the ability to control the audit
trail. That means that it should be guarded by CAP_AUDIT_CONTROL. I
think the same logic applies today. 

The difference is that with loginuid you needed to give processes able
to audit also the ability to change it. You do not want to tie the
ability to change container ids to the ability to audit. You want to be
able to do audit stuff (within the container) without allowing it to
change the container id.

Without a *kernel* policy on containerIDs you can't say what
security policy is being exempted. Without that you can't say what
capability is (or isn't) appropriate. You need a reason to have
a capability check that makes sense in the context of the kernel
security policy. Since we don't know what a container is in the
kernel, that's pretty hard. We don't create "fuzzy" capabilities
based on the trendy application behavior of the moment. If the
behavior is not related it audit, there's no reason for it, and
if it is, CAP_AUDIT_CONTROL works just fine. If this doesn't work
in your application security model I suggest that is where you
need to make changes.

Of course if we made container id a write-once property maybe there is
no need for controls at all, but I'm pretty sure there will be
situations where write-once may not be usable in practice.

quoted

The ability to arbitrarily set a container ID means the process has
the ability to indirectly control the audit trail.

The container Id can be used also for authorization purposes (by other
processes on the host), not just audit, I think this is why a separate
control has been proposed.

Simo.