<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>On Fri, 2019-07-19 at 11:00 -0500, Eric W. Biederman wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Paul Moore <<a href="mailto:paul@paul-moore.com">paul@paul-moore.com</a>> writes:</pre><pre><br></pre><pre></pre><pre>On Wed, Jul 17, 2019 at 8:52 PM Richard Guy Briggs <<a href="mailto:rgb@redhat.com">rgb@redhat.com</a>> wrote:</pre><pre></pre><pre>On 2019-07-16 19:30, Paul Moore wrote:</pre><pre><br></pre><pre>...</pre><pre><br></pre><pre></pre><pre></pre><pre>We can trust capable(CAP_AUDIT_CONTROL) for enforcing audit container</pre><pre>ID policy, we can not trust ns_capable(CAP_AUDIT_CONTROL).</pre><pre><br></pre><pre>Ok. So does a process in a non-init user namespace have two (or more)</pre><pre>sets of capabilities stored in creds, one in the init_user_ns, and one</pre><pre>in current_user_ns? Or does it get stripped of all its capabilities in</pre><pre>init_user_ns once it has its own set in current_user_ns? If the former,</pre><pre>then we can use capable(). If the latter, we need another mechanism, as</pre><pre>you have suggested might be needed.</pre><pre><br></pre><pre>Unfortunately I think the problem is that ultimately we need to allow</pre><pre>any container orchestrator that has been given privileges to manage</pre><pre>the audit container ID to also grant that privilege to any of the</pre><pre>child process/containers it manages. I don't believe we can do that</pre><pre>with capabilities based on the code I've looked at, and the</pre><pre>discussions I've had, but if you find a way I would leave to hear it.</pre><pre><br></pre><pre></pre><pre></pre><pre>If some random unprivileged user wants to fire up a container</pre><pre>orchestrator/engine in his own user namespace, then audit needs to be</pre><pre>namespaced. Can we safely discard this scenario for now?</pre><pre><br></pre><pre>I think the only time we want to allow a container orchestrator to</pre><pre>manage the audit container ID is if it has been granted that privilege</pre><pre>by someone who has that privilege already. In the zero-container, or</pre><pre>single-level of containers, case this is relatively easy, and we can</pre><pre>accomplish it using CAP_AUDIT_CONTROL as the privilege. If we start</pre><pre>nesting container orchestrators it becomes more complicated as we need</pre><pre>to be able to support granting and inheriting this privilege in a</pre><pre>manner; this is why I suggested a new mechanism *may* be necessary.</pre><pre><br></pre><pre><br></pre><pre>Let me segway a bit and see if I can get this conversation out of the</pre><pre>rut it seems to have drifted into.</pre><pre><br></pre><pre>Unprivileged containers and nested containers exist today and are going</pre><pre>to become increasingly common. Let that be a given.</pre><pre><br></pre><pre>As I recall the interesting thing for audit to log is actions by</pre><pre>privileged processes. Audit can log more but generally configuring</pre><pre>logging by of the actions of unprivileged users is effectively a self</pre><pre>DOS.</pre><pre><br></pre><pre>So I think the initial implementation can safely ignore actions of</pre><pre>nested containers and unprivileged containers because you don't care</pre><pre>about their actions. </pre><pre><br></pre><pre>If we start allow running audit in a container then we need to deal with</pre><pre>all of the nesting issues but until then I don't think you folks care.</pre><pre><br></pre><pre>Or am I wrong. Do the requirements for securely auditing things from</pre><pre>the kernel care about the actions of unprivileged users?</pre></blockquote><div><br></div><div>Depending on the sensitivity of the information the host or system manages, yes the actions of</div><div>unprivileged users is important to security auditing. Kernel auditing sometimes is the only opportunity</div><div>an incident responder has to identify a user's (privileged or not) interaction with the data the host manages.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre><br></pre><pre>Eric</pre><pre><br></pre><pre>--</pre><pre>Linux-audit mailing list</pre><pre><a href="mailto:Linux-audit@redhat.com">Linux-audit@redhat.com</a></pre><pre><a href="https://www.redhat.com/mailman/listinfo/linux-audit">https://www.redhat.com/mailman/listinfo/linux-audit</a></pre><pre><br></pre></blockquote></body></html>