Re: [Part1 PATCH 00/22] Add namespace support for audit
From: Daniel J Walsh
Date: Fri Jun 21 2013 - 05:51:50 EST
-----BEGIN PGP SIGNED MESSAGE-----
On 06/20/2013 11:48 PM, Gao feng wrote:
> On 06/20/2013 09:02 PM, Eric Paris wrote:
>> 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
>> 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.
> No, my v1 patchset only log the user audit message(which generated through
> auditctl -m "xxx") inside user namespace.
> I agree with that we should not simply log audit message in the child audit
> namespace. for some global resource related audit messages, they should be
> logged in init audit namespace too.
>> 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 and
>> init_audit namespace. Creating a new audit namespace should require
>> CAP_AUDIT_CONTROL in the init_user namespace. If instead we spawned a
>> new user namespace userns1 and try to create a new audit namespace, we
>> should STILL check for CAP_AUDIT_CONTROL in the init_user namespace.
> Ok, I can add this permission check in next version, though this seems a
> litter strictness when we make sure child audit namespace won't fool the
> init audit namespace,
>> Assuming we've spawned auditns1 in userns1 and want to spawn auditns2 it
>> should require CAP_AUDIT_CONTROL in userns1. So now you only have
>> permission to change your audit config (create a new audit namespace) if
>> you already had permission to change your current audit config.
>> Now how to handle coding this...
>> When the kernel receives an audit message on the netlink socket it can
>> always check the current->[whatever] to figure out which audit namespace
>> it came from. Then it can be processed accordingly...
> Yes, this situation is easy to handle, since we are in process context...
> but in some situations, we are not running in process context... as I
> mentioned, audit messages generated by netfilter rules. current process is
> untrustable. we can only get meaningful net namespace in this situation.
> Actually, it's meaningful to send net related audit messages to the user
> namespace which creates this net namespace.
>> Sending messages to the userspace auditd is a little more tricky. We
>> need to somehow map the audit namespace to a socket connected to auditd
>> in userspace. I'd imagine we'd have to either have per auditns backlog
>> queues and run one kauditd per audit namespace, or we'd have to tag the
>> skb's with the intended namespace somehow and then find the right socket
>> in kauditd. Either way it doesn't seem too onerous (although I admit, I
>> don't know how to code the per namespace kauditd right offhand)
> As I said in "[PATCH 04/22] netlink: Add compare function for
> netlink_table", netlink and socket are private resources of net namespace.
> socket has no idea which audit namespace it belongs to,unless we add a
> field to mark this. Through I think we can archive audit namespace in your
> way,but maybe we should hack into the net namespace. I don't think the
> network guys will like it.
> There is one more thing we have to do if we don't tie audit namespace to
> user namespace. we have to implement the audit proc
> file(/proc/<pid>/ns/audit) and the clone/unshare/setns parts.
> I still this my way is the simplest and can satisfy your requirement.
> -- Linux-audit mailing list Linux-audit@xxxxxxxxxx
Will I be able to use the audit namespace without the user namespace. I would
prefer to be able to use the audit namespace long before I am willing to take
a chance with the User Namespace for things like light weight virtualization
and securing processes with MAC.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/