Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/24/2013 07:47 AM, Richard Guy Briggs wrote:
On 13/12/09, Gao feng wrote:
> On 12/07/2013 05:31 AM, Serge E. Hallyn wrote:
>> Quoting Gao feng (gaofeng(a)cn.fujitsu.com):
>>> 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.
>>>
>>> And the login process in container may want to setup
>>> /proc/<pid>/loginuid, right now this value is unalterable
>>> once it being set. this will also broke the login problem
>>> in container. After this patchset, we can reset this loginuid
>>> to zero if task is running in a new audit namespace.
>>>
>>> Same with v1 patchset, in this patchset, only the privileged
>>> user in init_audit_ns and init_user_ns has rights to
>>> add/del audit rules. and these rules are gloabl. all
>>> audit namespace will comply with the rules.
>>>
>>> Compared with v1, v2 patch has some big changes.
>>> 1, the audit namespace is not assigned to user namespace.
>>> since there is no available bit of flags for clone, we
>>> create audit namespace through netlink, patch[18/20]
>>> introduces a new audit netlink type AUDIT_CREATE_NS.
>>> the privileged user in userns has rights to create a
>>> audit namespace, it means the unprivileged user can
>>> create auditns through create userns first. In order
>>> to prevent them from doing harm to host, the default
>>> audit_backlog_limit of un-init-audit-ns is zero(means
>>> audit is unavailable in audit namespace). and it can't
>>> be changed in auditns through netlink.
>>
>> So the unprivileged user can create an audit-ns, but can't
>> then actually send any messages there? I guess setting it
>> to something small would just be hacky?
>
> Yes, if unprivileged user wants to send audit message, he should
> ask privileged user to setup the audit_backlog_limit for him.
>
> I know it's a little of hack, but I don't have good idea :(
There's a recent patch that actually clarifies the way
audit_backlog_limit works, since different parts of the code seemed to
think different things. It now means unlimited, since there are other
places to shut off logging.
audit: allow unlimited backlog queue
Yep, thanks for your information, we can set a negative number to backlog_limit
to mark there is no available buff for this audit ns.
At first, I'd say each audit_ns should be able to set its own
audit_backlog_limit. The most obvious argument against this would be
the vulnerability of a DoS.
There are two problem we should conside, auditns costs lot's of memory by
setting large backlog_limit and costs lot's of cpu resources by generating
audit log all the time. So I think the privileged user should have the ability
to limit the backlog len.
And I think it's not very necessary to keep on allowing auditns to set its own
audit_backlog_limit. if you think this is necessary, we can add a field max_backlog_limit
for per audit namespace. and set this value when we create auditns.
And seem like the audit_rate_limit should not be change by unprivileged user.
I don't know if I really follow your request...
Could there be some automatic metrics to
set sub audit_ns backlog limits, such as default to the same as
init_audit_ns and have the init_audit_ns override those defaults?
Could this be done per user like ulimiit?
I think something like ulimit cannot help us.
we should set sub-auditns's backlog_limit in parent auditns..
so maybe the proc file is the best way.