Quoting Gao feng (gaofeng@xxxxxxxxxxxxxx): > 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 :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
