Aleksa Sarai <asarai@xxxxxxx> writes: >>> The security implications are that anything that can change the label >>> could also hide itself and its doings from the audit system and thus >>> would be used as a means to evade detection. I actually think this >>> means the label should be write once (once you've set it, you can't >>> change it) ... >> >> Richard and I have talked about a write once approach, but the >> thinking was that you may want to allow a nested container >> orchestrator (Why? I don't know, but people always want to do the >> craziest things.) and a write-once policy makes that impossible. If >> we punt on the nested orchestrator, I believe we can seriously think >> about a write-once policy to simplify things. > > Nested containers are a very widely used use-case (see LXC system containers, > inside of which people run other container runtimes). So I would definitely > consider it something that "needs to be supported in some way". While the LXC > guys might be a *tad* crazy, the use-case isn't. :P Of course some of that gets to running auditd inside a container which we don't have yet either. So I think to start it is perfectly fine to figure out the non-nested case first and what makes sense there. Then to sort out the nested container case. The solution might be that a process gets at most one id per ``audit namespace''. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
