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

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
>>> 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.
>> 
> 
> 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 
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
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/

iEYEARECAAYFAlHEIiEACgkQrlYvE4MpobP8awCcD4xO34I4IDD+qeHQLPFtWM0q
vnMAn1PTatEUfPkeQG1+dG4ULKpOLCoB
=nrRz
-----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/