On Sat, 2021-12-11 at 10:38 -0500, Stefan Berger wrote: > On 12/11/21 10:02, Serge E. Hallyn wrote: > > IMO yes it is unsafe, however I concede that I am not sufficiently > > familiar with the policy language. At least Stefan and Mimi (IIUC) > > want the host policy language to be able to specify cases where an > > IMA ns can be configured. What's not clear to me is what sorts of > > triggers the host IMA policy could specify that would safely > > identify a IMA ns generation > > trigger. > > > > Stefan, would you mind showing what such a policy statement would > > look like? Does it amount to "/usr/bin/runc may create an IMA ns > > which escapes current policy" ? Or is it by UID, or any file which > > has a certain xattr on it? > > If this policy here is active on the host then file executions > (BPRM_CHECK) of uid=0 should be measured and audited on the host in > any IMA namespace that uid=0 may create. We achieve this with > hierarchical processing (v6: 10/17). > > measure func=BPRM_CHECK mask=MAY_EXEC uid=0 > > audit func=BPRM_CHECK mask=MAY_EXEC uid=0 Or perhaps to put another way that might be more useful to unprivileged containers: if you strip the uid=0 from both of those statements, you get a rule that logs and audits any execution. Once you enter the IMA namespace, in that namespace you see nothing, but outside the parent is still logging and auditing all executions, including those inside the container, according to its measure/audit all executions rule. The container can't turn that off by writes to its policy file. So the container can never escape any policy rule imposed by the parent James
