Quoting Gao feng (gaofeng(a)cn.fujitsu.com):
On 12/07/2013 06:12 AM, Serge E. Hallyn wrote:
> Quoting Gao feng (gaofeng(a)cn.fujitsu.com):
>> 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.
-serge