Re: [Part1 PATCH 00/22] Add namespace support for audit

On Thu, 2013-06-20 at 11:02 +0800, Gao feng wrote: > On 06/20/2013 04:51 AM, Eric Paris wrote: > > On Wed, 2013-06-19 at 16:49 -0400, Aristeu Rozanski wrote: > >> On Wed, Jun 19, 2013 at 09:53:32AM +0800, Gao feng wrote: > >>> This patchset is first part of namespace support for audit. > >>> in this patchset, the mainly resources of audit system have > >>> been isolated. the audit filter, rules havn't been isolated > >>> now. It will be implemented in Part2. We finished the isolation > >>> of user audit message in this patchset. > >>> > >>> I choose to assign audit to the user namespace. > >>> Right now,there are six kinds of namespaces, such as > >>> net, mount, ipc, pid, uts and user. the first five > >>> namespaces have special usage. the audit isn't suitable to > >>> belong to these five namespaces, And since the flag of system > >>> call clone is in short supply, we can't provide a new flag such > >>> as CLONE_NEWAUDIT to enable audit namespace separately. so the > >>> user namespace may be the best choice. > >> > >> I thought it was said on the last submission that to tie userns and > >> audit namespace would be a bad idea? > > > > I consider it a non-starter. unpriv users are allowed to launch their > > own user namespace. The whole point of audit is to have only a priv > > user be allowed to make changes. If you tied audit namespace to user > > namespace you grant an unpriv user the ability to modify audit. > > > > I understand your views. > > But ven the unpriv user are allowed to make changes, they can do no harm. > they can only make changes on the audit namespace they created.they can > only communicate with the audit namespace they created. Imagine I set up my machine to audit all user access to super secret information. With your patch set all an malicious user has to do is create a new user namespace. Now when he accesses the super secret information it will be logged inside the user namespace he created. So he can just dump those logs in the trash.

I believe that each audit namespace should require priv (CAP_AUDIT_CONTROL) in the user namespace that created the current audit namespace. So lets say the machine boots and we are in the init_user