On 12/10/2013 02:26 AM, Serge Hallyn wrote: > Quoting Gao feng (gaofeng@xxxxxxxxxxxxxx): >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: >>> Quoting Gao feng (gaofeng@xxxxxxxxxxxxxx): >>>> Hi >>>> >>>> On 10/24/2013 03:31 PM, Gao feng wrote: >>>>> Here is the v1 patchset: http://lwn.net/Articles/549546/ >>>>> >>>>> The main target of this patchset is allowing user in audit >>>>> namespace to generate the USER_MSG type of audit message, >>>>> some userspace tools need to generate audit message, or >>>>> these tools will broken. >>>>> >>>> >>>> I really need this feature, right now,some process such as >>>> logind are broken in container becase we leak of this feature. >>> >>> Your set doesn't address loginuid though right? How exactly do you >>> expect to do that? If user violates MAC policy and audit msg is >>> sent to init user ns by mac subsys, you need the loginuid from >>> init_audit_ns. where will that be stored if you allow updates >>> of loginuid in auditns? >>> >> This patchset doesn't include the loginuid part. >> >> the loginuid is stored in task as before. >> In my opinion, when task creates a new audit namespace, this task's >> loginuid will be reset to zero, so the children tasks can set their >> loginuid. Does this change break the MAC? > > I think so, yes. In an LSPP selinux environment, if the task > manages to trigger an selinux deny rule which is audited, then > the loginuid must make sense on the host. Now presumably it > will get translated to the mapped host uid, and we can figure > out the host uid owning it through /etc/subuid. But that adds > /etc/subuid as a new part of the TCB without any warning <shrug> > So in that sense, for LSPP, it breaks it. > Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
