Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/21/2013 11:48 AM, 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
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/21/2013 11:48 AM, 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
Re: [Part1 PATCH 00/22] Add namespace support for audit
Aristeu Rozanski writes: > On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: >> Gao feng writes: >> >> > On 06/20/2013 11:02 AM, Gao feng wrote: >> >> If we don't tie audit to user namespace, there is still one problem. >> > >> > One more problem. some audit messages are generated by some net subsystem >> > such as netfilter. If we don't tie audit to user namespace, we have no >> > idea where these audit messages should go. there is no relationship between >> > net namespace and audit namespace while we can get user namespace through >> > net user namespace. >> >> I am in favor of the user namespace tie in. >> >> I am in favor of running a per user namespace audit filter once per user >> namespace walking up the user namespace hierarchy. Each filter would >> deliver messages to a different userspace audit daemon. >> >> Until we agreement to go that far I am not certain the kernel generated >> audit messages should go anywhere except to the global audit daemon. >> >> I think on an individual basis we can look at kernel audit messages and >> see if they should go to just the global user namespace. Just the user >> namspace of the relevant network stack. Or if the message should go to >> the audit daemon of every user namespace that is an ancestor of some >> starting user namespace. >> >> But please let's error on the side of caution here. > > Let's say I'd like to use userns but still have a single and global > auditd. By definition the kernel auditd functionality is broken if we don't allow a global auditd. So that will be allowed. > Dropping the capability will be required for that? No. Dropping capabilities and being in a state where you can never interact with the primary audit context is required to safely have access to a subordinate audit context. Never being able to intereact with the primary audit context removes all possibility of confusing a privileged application and break the security model. Entering a user namespace by definition drops all capabilities in a non-recoverable way. Which makes being in a user namespace a sufficient condition to use a subordinate audit context. > That sounds > bad. The fact new user namespaces will want to control the separated > audit namespace doesn't require tie in. No. The fact that you can gain root privileges by executing a suid root application when not in a user namespace requires a tie in. In summary. A subordinate audit context is not safe if you can still execute a suid root application and become root. The interesting use case is inside of a user namespace, which never allows gaining capabilities outside of the user namespace. Which makes a tie in with user namespaces sensible, as it never allows subverting the current mechanisms and it is where people want the functionality. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: > Gao feng writes: > > > On 06/20/2013 11:02 AM, Gao feng wrote: > >> If we don't tie audit to user namespace, there is still one problem. > > > > One more problem. some audit messages are generated by some net subsystem > > such as netfilter. If we don't tie audit to user namespace, we have no > > idea where these audit messages should go. there is no relationship between > > net namespace and audit namespace while we can get user namespace through > > net user namespace. > > I am in favor of the user namespace tie in. > > I am in favor of running a per user namespace audit filter once per user > namespace walking up the user namespace hierarchy. Each filter would > deliver messages to a different userspace audit daemon. > > Until we agreement to go that far I am not certain the kernel generated > audit messages should go anywhere except to the global audit daemon. > > I think on an individual basis we can look at kernel audit messages and > see if they should go to just the global user namespace. Just the user > namspace of the relevant network stack. Or if the message should go to > the audit daemon of every user namespace that is an ancestor of some > starting user namespace. > > But please let's error on the side of caution here. Let's say I'd like to use userns but still have a single and global auditd. Dropping the capability will be required for that? That sounds bad. The fact new user namespaces will want to control the separated audit namespace doesn't require tie in. -- Aristeu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: On 06/20/2013 11:02 AM, Gao feng wrote: If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. I am in favor of the user namespace tie in. I am in favor of running a per user namespace audit filter once per user namespace walking up the user namespace hierarchy. Each filter would deliver messages to a different userspace audit daemon. Until we agreement to go that far I am not certain the kernel generated audit messages should go anywhere except to the global audit daemon. I think on an individual basis we can look at kernel audit messages and see if they should go to just the global user namespace. Just the user namspace of the relevant network stack. Or if the message should go to the audit daemon of every user namespace that is an ancestor of some starting user namespace. But please let's error on the side of caution here. Let's say I'd like to use userns but still have a single and global auditd. Dropping the capability will be required for that? That sounds bad. The fact new user namespaces will want to control the separated audit namespace doesn't require tie in. -- Aristeu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Aristeu Rozanski a...@redhat.com writes: On Thu, Jun 20, 2013 at 03:01:09PM -0700, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: On 06/20/2013 11:02 AM, Gao feng wrote: If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. I am in favor of the user namespace tie in. I am in favor of running a per user namespace audit filter once per user namespace walking up the user namespace hierarchy. Each filter would deliver messages to a different userspace audit daemon. Until we agreement to go that far I am not certain the kernel generated audit messages should go anywhere except to the global audit daemon. I think on an individual basis we can look at kernel audit messages and see if they should go to just the global user namespace. Just the user namspace of the relevant network stack. Or if the message should go to the audit daemon of every user namespace that is an ancestor of some starting user namespace. But please let's error on the side of caution here. Let's say I'd like to use userns but still have a single and global auditd. By definition the kernel auditd functionality is broken if we don't allow a global auditd. So that will be allowed. Dropping the capability will be required for that? No. Dropping capabilities and being in a state where you can never interact with the primary audit context is required to safely have access to a subordinate audit context. Never being able to intereact with the primary audit context removes all possibility of confusing a privileged application and break the security model. Entering a user namespace by definition drops all capabilities in a non-recoverable way. Which makes being in a user namespace a sufficient condition to use a subordinate audit context. That sounds bad. The fact new user namespaces will want to control the separated audit namespace doesn't require tie in. No. The fact that you can gain root privileges by executing a suid root application when not in a user namespace requires a tie in. In summary. A subordinate audit context is not safe if you can still execute a suid root application and become root. The interesting use case is inside of a user namespace, which never allows gaining capabilities outside of the user namespace. Which makes a tie in with user namespaces sensible, as it never allows subverting the current mechanisms and it is where people want the functionality. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Daniel J Walsh writes: > 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. I will be very surprised if we settle on a design that allows it. I still think even the existence of multiple audit contexts is a little iffy but the desire seems strong enough Gao feng will probably work through all of the issues. Without restricting processes to a user namespace at the same time as restricting them to an audit context it becomes very easy to violate the important audit policies and to bury user space generated messages from privileged userspace applications. At least in a user namespace we know you are not privileged with respect to the rest of the system, so we would only be dealing with userspace messages you would not be able to generate otherwise. As for taking a chance. You will probably safer with a simultaneous use of user namespaces and having processes secured with a MAC. To the best of my knowledge previous solutions have only been really safe when you trusted the processes inside not to be malicious. A user namespace at least means you can stop using uid 0 inside of your light weight virtualization. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
-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
Re: [Part1 PATCH 00/22] Add namespace support for audit
-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
Re: [Part1 PATCH 00/22] Add namespace support for audit
Daniel J Walsh dwa...@redhat.com writes: 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. I will be very surprised if we settle on a design that allows it. I still think even the existence of multiple audit contexts is a little iffy but the desire seems strong enough Gao feng will probably work through all of the issues. Without restricting processes to a user namespace at the same time as restricting them to an audit context it becomes very easy to violate the important audit policies and to bury user space generated messages from privileged userspace applications. At least in a user namespace we know you are not privileged with respect to the rest of the system, so we would only be dealing with userspace messages you would not be able to generate otherwise. As for taking a chance. You will probably safer with a simultaneous use of user namespaces and having processes secured with a MAC. To the best of my knowledge previous solutions have only been really safe when you trusted the processes inside not to be malicious. A user namespace at least means you can stop using uid 0 inside of your light weight virtualization. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/21/2013 06:01 AM, Eric W. Biederman wrote: > Gao feng writes: > >> On 06/20/2013 11:02 AM, Gao feng wrote: >>> If we don't tie audit to user namespace, there is still one problem. >> >> One more problem. some audit messages are generated by some net subsystem >> such as netfilter. If we don't tie audit to user namespace, we have no >> idea where these audit messages should go. there is no relationship between >> net namespace and audit namespace while we can get user namespace through >> net user namespace. > > I am in favor of the user namespace tie in. > > I am in favor of running a per user namespace audit filter once per user > namespace walking up the user namespace hierarchy. Each filter would > deliver messages to a different userspace audit daemon. > Agree, this sounds reasonable. > Until we agreement to go that far I am not certain the kernel generated > audit messages should go anywhere except to the global audit daemon. There are some audit messages that we sure where they should go, we can start from them firstly. > > I think on an individual basis we can look at kernel audit messages and > see if they should go to just the global user namespace. Just the user > namspace of the relevant network stack. Or if the message should go to > the audit daemon of every user namespace that is an ancestor of some > starting user namespace. > > But please let's error on the side of caution here. > > Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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
Re: [Part1 PATCH 00/22] Add namespace support for audit
Gao feng writes: > On 06/20/2013 11:02 AM, Gao feng wrote: >> If we don't tie audit to user namespace, there is still one problem. > > One more problem. some audit messages are generated by some net subsystem > such as netfilter. If we don't tie audit to user namespace, we have no > idea where these audit messages should go. there is no relationship between > net namespace and audit namespace while we can get user namespace through > net user namespace. I am in favor of the user namespace tie in. I am in favor of running a per user namespace audit filter once per user namespace walking up the user namespace hierarchy. Each filter would deliver messages to a different userspace audit daemon. Until we agreement to go that far I am not certain the kernel generated audit messages should go anywhere except to the global audit daemon. I think on an individual basis we can look at kernel audit messages and see if they should go to just the global user namespace. Just the user namspace of the relevant network stack. Or if the message should go to the audit daemon of every user namespace that is an ancestor of some starting user namespace. But please let's error on the side of caution here. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Quoting Eric Paris (epa...@redhat.com): > 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. Right, I thought I'd pointed this out last time - it makes LSPP certification impossible. > 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 The problem with this is that ... people will then hand out CAP_AUDIT_CONTROL :) I'd be happier with Eric Biederman's suggestion: You can create a new audit namespace, but all of the initial audit namespace's filters still (separately) apply to you. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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. 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... 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) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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. 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... 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) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Quoting Eric Paris (epa...@redhat.com): 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. Right, I thought I'd pointed this out last time - it makes LSPP certification impossible. 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 The problem with this is that ... people will then hand out CAP_AUDIT_CONTROL :) I'd be happier with Eric Biederman's suggestion: You can create a new audit namespace, but all of the initial audit namespace's filters still (separately) apply to you. -serge -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Gao feng gaof...@cn.fujitsu.com writes: On 06/20/2013 11:02 AM, Gao feng wrote: If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. I am in favor of the user namespace tie in. I am in favor of running a per user namespace audit filter once per user namespace walking up the user namespace hierarchy. Each filter would deliver messages to a different userspace audit daemon. Until we agreement to go that far I am not certain the kernel generated audit messages should go anywhere except to the global audit daemon. I think on an individual basis we can look at kernel audit messages and see if they should go to just the global user namespace. Just the user namspace of the relevant network stack. Or if the message should go to the audit daemon of every user namespace that is an ancestor of some starting user namespace. But please let's error on the side of caution here. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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. -- To
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/21/2013 06:01 AM, Eric W. Biederman wrote: Gao feng gaof...@cn.fujitsu.com writes: On 06/20/2013 11:02 AM, Gao feng wrote: If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. I am in favor of the user namespace tie in. I am in favor of running a per user namespace audit filter once per user namespace walking up the user namespace hierarchy. Each filter would deliver messages to a different userspace audit daemon. Agree, this sounds reasonable. Until we agreement to go that far I am not certain the kernel generated audit messages should go anywhere except to the global audit daemon. There are some audit messages that we sure where they should go, we can start from them firstly. I think on an individual basis we can look at kernel audit messages and see if they should go to just the global user namespace. Just the user namspace of the relevant network stack. Or if the message should go to the audit daemon of every user namespace that is an ancestor of some starting user namespace. But please let's error on the side of caution here. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/20/2013 05:03 AM, Eric W. Biederman wrote: > Eric Paris writes: > >> 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. >> >> NAK. >> >> If there are not clone flags you will either need to only do this from >> unshare and not from clone, or get more flags to clone > > I completely agree that only priveleged user should be able to make > changes. > > On the flip side, I don't know if this is at all interesting unless we > have a solution that works for users in unprivileged user namespaces. > Something like having the possibility of two or more instances of audit > working on every action. One for each layer of privilege. > > Gao feng, how do you want to use the audit infrastructure? > I want the root user in container can use the audit related api (audit_open,audit_log_user_message..) and some network related audit messages generated by container shouldn't be logged to host. Thanks, Gao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/20/2013 11:02 AM, Gao feng wrote: > If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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. Before we have mount namespace, only priv user can change the mount information, And with mount namespace & user namespace, the unpriv user can create their own user namespace,and then create they own mount namespace. so the unpriv user have the ability to change their own mount namespace, since they become the priv user in their user namespace. The only difference to the mount namespace is that,audit namespace is created automatically when creating user namespace,So the unpriv users even have no chance to change the init audit namespace. the unpriv users can't make changes on the init audit namespace. In this patchset, I already do some check to make sure only the priv user in init user namespace can change the rate_limit,audit_failure, backlog_limit. I think we can absolutely make the unpriv users can't do some bad influence on the whole system. If we don't tie audit to user namespace, there is still one problem. how audit netlink works? In this patchset, I use sock_net(sk)->user_ns to decide if two audit netlink sockets can communicate with each other. if we don't tie audit to user namespace, we have to add one field such as 'auditns' in socket and use sk1->auditns == sk2->auditns to decide if two audit netlink sockets belong to same audit namespace. I think this is a little of overhead and ugly. > NAK. > > If there are not clone flags you will either need to only do this from > unshare and not from clone, or get more flags to clone > If you still think it's unsafe or unreasonable for unpriv users to create audit namespace, I think we can only allow priv user to create audit ns when they creating user namespace. If unpriv users create new user namespace, we can simply don't create new audit namespace for them. I can't find out a better solution... Thanks, Gao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Eric Paris writes: > 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. > > NAK. > > If there are not clone flags you will either need to only do this from > unshare and not from clone, or get more flags to clone I completely agree that only priveleged user should be able to make changes. On the flip side, I don't know if this is at all interesting unless we have a solution that works for users in unprivileged user namespaces. Something like having the possibility of two or more instances of audit working on every action. One for each layer of privilege. Gao feng, how do you want to use the audit infrastructure? Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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. NAK. If there are not clone flags you will either need to only do this from unshare and not from clone, or get more flags to clone -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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? -- Aristeu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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? -- Aristeu -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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. NAK. If there are not clone flags you will either need to only do this from unshare and not from clone, or get more flags to clone -Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
Eric Paris epa...@redhat.com writes: 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. NAK. If there are not clone flags you will either need to only do this from unshare and not from clone, or get more flags to clone I completely agree that only priveleged user should be able to make changes. On the flip side, I don't know if this is at all interesting unless we have a solution that works for users in unprivileged user namespaces. Something like having the possibility of two or more instances of audit working on every action. One for each layer of privilege. Gao feng, how do you want to use the audit infrastructure? Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
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. Before we have mount namespace, only priv user can change the mount information, And with mount namespace user namespace, the unpriv user can create their own user namespace,and then create they own mount namespace. so the unpriv user have the ability to change their own mount namespace, since they become the priv user in their user namespace. The only difference to the mount namespace is that,audit namespace is created automatically when creating user namespace,So the unpriv users even have no chance to change the init audit namespace. the unpriv users can't make changes on the init audit namespace. In this patchset, I already do some check to make sure only the priv user in init user namespace can change the rate_limit,audit_failure, backlog_limit. I think we can absolutely make the unpriv users can't do some bad influence on the whole system. If we don't tie audit to user namespace, there is still one problem. how audit netlink works? In this patchset, I use sock_net(sk)-user_ns to decide if two audit netlink sockets can communicate with each other. if we don't tie audit to user namespace, we have to add one field such as 'auditns' in socket and use sk1-auditns == sk2-auditns to decide if two audit netlink sockets belong to same audit namespace. I think this is a little of overhead and ugly. NAK. If there are not clone flags you will either need to only do this from unshare and not from clone, or get more flags to clone If you still think it's unsafe or unreasonable for unpriv users to create audit namespace, I think we can only allow priv user to create audit ns when they creating user namespace. If unpriv users create new user namespace, we can simply don't create new audit namespace for them. I can't find out a better solution... Thanks, Gao -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/20/2013 11:02 AM, Gao feng wrote: If we don't tie audit to user namespace, there is still one problem. One more problem. some audit messages are generated by some net subsystem such as netfilter. If we don't tie audit to user namespace, we have no idea where these audit messages should go. there is no relationship between net namespace and audit namespace while we can get user namespace through net user namespace. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Part1 PATCH 00/22] Add namespace support for audit
On 06/20/2013 05:03 AM, Eric W. Biederman wrote: Eric Paris epa...@redhat.com writes: 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. NAK. If there are not clone flags you will either need to only do this from unshare and not from clone, or get more flags to clone I completely agree that only priveleged user should be able to make changes. On the flip side, I don't know if this is at all interesting unless we have a solution that works for users in unprivileged user namespaces. Something like having the possibility of two or more instances of audit working on every action. One for each layer of privilege. Gao feng, how do you want to use the audit infrastructure? I want the root user in container can use the audit related api (audit_open,audit_log_user_message..) and some network related audit messages generated by container shouldn't be logged to host. Thanks, Gao -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Part1 PATCH 00/22] Add namespace support for audit
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. [Patch 4/21] add a compare function pointer for netlink table, so audit subsystem can use it's self-defined compare function to make sure audit netlink sockets can communicate with each other when they in the same user namespace. this patch has been merged into David's net-next tree. There is one point that some people may dislike,in [PATCH 3/21], the kernel side audit netlink socket is created only when we create the first netns for the userns, and this userns will hold the netns until we destroy this userns. It also means if we only unshare the user namespace, the audit is unavailable since we don't have audit netlink socket. if we should unshare user and net namespace both. change from RFC: 1, Move the cleanup patches to the head of this patchset. 2, Fix a scheduling while atomic BUG. This bug is caused by kthread_stop in audit_free_user_ns. 3, Only allow init user namespace to change backlog_limit. 4, Audit subsystem is available only when kernel side audit netlink socket has been created. 5, Only isolate the basic resources of audit, and only make user audit message namespace aware. This patchset is based on linus' linux tree. You can pull this patchset from: git://github.com/gao-feng/auditns.git The following changes since commit 8177a9d79c0e942dcac3312f15585d0344d505a5 "lseek(fd, n, SEEK_END) does *not* go to eof - n" are available in the git repository at: git://github.com/gao-feng/auditns.git for you to fetch changes up to 85c36b981ac692ec18e362ba484629a457d50cb2 "Audit: Allow GET,SET,USER MSG operations in uninit user namespace" Gao feng (22): Audit: change type of audit_ever_enabled to bool Audit: remove duplicate comments Audit: make audit kernel side netlink sock per userns netlink: Add compare function for netlink_table Audit: implement audit self-defined compare function Audit: make audit_skb_queue per user namespace Audit: make audit_skb_hold_queue per user namespace Audit: make kauditd_task per user namespace Audit: make audit_nlk_portid per user namesapce Audit: make audit_enabled per user namespace Audit: make audit_ever_enabled per user namespace Audit: make audit_initialized per user namespace Audit: only allow init user namespace to change rate limit Audit: only allow init user namespace to change audit_failure Audit: only allow init user namespace to change backlog_limit Audit: make kauditd_wait per user namespace Audit: make audit_backlog_wait per user namespace Audit: introduce new audit logging interface for user namespace Audit: pass proper user namespace to audit_log_common_recv_msg Audit: Log audit config change in uninit user namespace Audit: send reply message to the auditd in proper user namespace Audit: Allow GET,SET,USER MSG operations in uninit user namespace include/linux/audit.h | 39 +++- include/linux/netlink.h| 1 + include/linux/user_namespace.h | 33 ++- kernel/audit.c | 452 + kernel/audit.h | 7 +- kernel/auditsc.c | 11 +- kernel/user_namespace.c| 3 + net/netlink/af_netlink.c | 32 ++- net/netlink/af_netlink.h | 1 + 9 files changed, 387 insertions(+), 192 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Part1 PATCH 00/22] Add namespace support for audit
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. [Patch 4/21] add a compare function pointer for netlink table, so audit subsystem can use it's self-defined compare function to make sure audit netlink sockets can communicate with each other when they in the same user namespace. this patch has been merged into David's net-next tree. There is one point that some people may dislike,in [PATCH 3/21], the kernel side audit netlink socket is created only when we create the first netns for the userns, and this userns will hold the netns until we destroy this userns. It also means if we only unshare the user namespace, the audit is unavailable since we don't have audit netlink socket. if we should unshare user and net namespace both. change from RFC: 1, Move the cleanup patches to the head of this patchset. 2, Fix a scheduling while atomic BUG. This bug is caused by kthread_stop in audit_free_user_ns. 3, Only allow init user namespace to change backlog_limit. 4, Audit subsystem is available only when kernel side audit netlink socket has been created. 5, Only isolate the basic resources of audit, and only make user audit message namespace aware. This patchset is based on linus' linux tree. You can pull this patchset from: git://github.com/gao-feng/auditns.git The following changes since commit 8177a9d79c0e942dcac3312f15585d0344d505a5 lseek(fd, n, SEEK_END) does *not* go to eof - n are available in the git repository at: git://github.com/gao-feng/auditns.git for you to fetch changes up to 85c36b981ac692ec18e362ba484629a457d50cb2 Audit: Allow GET,SET,USER MSG operations in uninit user namespace Gao feng (22): Audit: change type of audit_ever_enabled to bool Audit: remove duplicate comments Audit: make audit kernel side netlink sock per userns netlink: Add compare function for netlink_table Audit: implement audit self-defined compare function Audit: make audit_skb_queue per user namespace Audit: make audit_skb_hold_queue per user namespace Audit: make kauditd_task per user namespace Audit: make audit_nlk_portid per user namesapce Audit: make audit_enabled per user namespace Audit: make audit_ever_enabled per user namespace Audit: make audit_initialized per user namespace Audit: only allow init user namespace to change rate limit Audit: only allow init user namespace to change audit_failure Audit: only allow init user namespace to change backlog_limit Audit: make kauditd_wait per user namespace Audit: make audit_backlog_wait per user namespace Audit: introduce new audit logging interface for user namespace Audit: pass proper user namespace to audit_log_common_recv_msg Audit: Log audit config change in uninit user namespace Audit: send reply message to the auditd in proper user namespace Audit: Allow GET,SET,USER MSG operations in uninit user namespace include/linux/audit.h | 39 +++- include/linux/netlink.h| 1 + include/linux/user_namespace.h | 33 ++- kernel/audit.c | 452 + kernel/audit.h | 7 +- kernel/auditsc.c | 11 +- kernel/user_namespace.c| 3 + net/netlink/af_netlink.c | 32 ++- net/netlink/af_netlink.h | 1 + 9 files changed, 387 insertions(+), 192 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
