Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit

On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: > Quoting Gao feng (gaofeng(a)cn.fujitsu.com): > > On 12/10/2013 02:26 AM, Serge Hallyn wrote: > > > 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. > > > > > > > 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. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the

kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record.

It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know...

Namespaces scare me...