Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/24/2013 07:47 AM, Richard Guy Briggs wrote: > On 13/12/09, Gao feng wrote: >> On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc//loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. >>> >>> So the unprivileged user can create an audit-ns, but can't >>> then actually send any messages there? I guess setting it >>> to something small would just be hacky? >> >> Yes, if unprivileged user wants to send audit message, he should >> ask privileged user to setup the audit_backlog_limit for him. >> >> I know it's a little of hack, but I don't have good idea :( > > There's a recent patch that actually clarifies the way > audit_backlog_limit works, since different parts of the code seemed to > think different things. It now means unlimited, since there are other > places to shut off logging. > audit: allow unlimited backlog queue Yep, thanks for your information, we can set a negative number to backlog_limit to mark there is no available buff for this audit ns. > > At first, I'd say each audit_ns should be able to set its own > audit_backlog_limit. The most obvious argument against this would be > the vulnerability of a DoS. There are two problem we should conside, auditns costs lot's of memory by setting large backlog_limit and costs lot's of cpu resources by generating audit log all the time. So I think the privileged user should have the ability to limit the backlog len. And I think it's not very necessary to keep on allowing auditns to set its own audit_backlog_limit. if you think this is necessary, we can add a field max_backlog_limit for per audit namespace. and set this value when we create auditns. And seem like the audit_rate_limit should not be change by unprivileged user. I don't know if I really follow your request... > Could there be some automatic metrics to > set sub audit_ns backlog limits, such as default to the same as > init_audit_ns and have the init_audit_ns override those defaults? > Could this be done per user like ulimiit? > I think something like ulimit cannot help us. we should set sub-auditns's backlog_limit in parent auditns.. so maybe the proc file is the best way. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/21/2013 05:15 AM, Serge E. Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: >>> Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> On 12/10/2013 02:26 AM, Serge Hallyn wrote: >>> Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> Hi >> >> On 10/24/2013 03:31 PM, Gao feng wrote: >>> Here is the v1 patchset: http://lwn.net/Articles/549546/ >>> >>> The main target of this patchset is allowing user in audit >>> namespace to generate the USER_MSG type of audit message, >>> some userspace tools need to generate audit message, or >>> these tools will broken. >>> >> >> I really need this feature, right now,some process such as >> logind are broken in container becase we leak of this feature. > > Your set doesn't address loginuid though right? How exactly do you > expect to do that? If user violates MAC policy and audit msg is > sent to init user ns by mac subsys, you need the loginuid from > init_audit_ns. where will that be stored if you allow updates > of loginuid in auditns? > This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? >>> >>> I think so, yes. In an LSPP selinux environment, if the task >>> manages to trigger an selinux deny rule which is audited, then >>> the loginuid must make sense on the host. Now presumably it >>> will get translated to the mapped host uid, and we can figure >>> out the host uid owning it through /etc/subuid. But that adds >>> /etc/subuid as a new part of the TCB without any warning >>> So in that sense, for LSPP, it breaks it. >>> >> >> Looks like my opinion is incorrect. >> >> In the audit-next tree, Eric added a new audit feature to allow >> privileged >> user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE >> is disabled, the privileged user can reset/set the loginuid of task. I >> think this way is safe since only privileged user can do the change. >> >> So I will not change the loginuid part. >> >> Thanks for your information Serge :) > > Unfortunately this makes the patchset much less compelling :) The > problem I was looking into is that a container running in a user > namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not > capable(CAP_AUDIT_*)) set loginuids at all. > > Which from an LSPP pov is correct; which is why I was hoping you were > going to have the audit namespaces be hierarchical, with a task in a > level 2 audit ns having two loginuids - one in his own auditns, and > one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the >>> >>> So long as the kernel stores the kuid_t (which the only sane thing to >>> do) that is a non-issue. >>> kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. >>> >>> Yup, that should go without saying. Use kuid_t in kernel and translate >>> at the kernel-user boundary. >>> >> >> I can implement audit namespace as a hierarchy, give per auditns a level >> value >> and a pointer which point to parent auditns. >> >> but for the loginuid part, I think we can implement it after we push the >> audit >> ns into the upstream. >> >> Is this ok? > > Well as I"ve said the loginuid part is the only one that interests > me. I'll be out most of the rest of the year, but I'll review any > patchset you send for what seems to me to be correctness :) > Thanks for your help! As soon as the frame of auditns being accepted, I think it's easily to push the loginuid part. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/21/2013 05:15 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the So long as the kernel stores the kuid_t (which the only sane thing to do) that is a non-issue. kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. Yup, that should go without saying. Use kuid_t in kernel and translate at the kernel-user boundary. I can implement audit namespace as a hierarchy, give per auditns a level value and a pointer which point to parent auditns. but for the loginuid part, I think we can implement it after we push the audit ns into the upstream. Is this ok? Well as Ive said the loginuid part is the only one that interests me. I'll be out most of the rest of the year, but I'll review any patchset you send for what seems to me to be correctness :) Thanks for your help! As soon as the frame of auditns being accepted, I think it's easily to push the loginuid part. :) -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/24/2013 07:47 AM, Richard Guy Briggs wrote: On 13/12/09, Gao feng wrote: On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. So the unprivileged user can create an audit-ns, but can't then actually send any messages there? I guess setting it to something small would just be hacky? Yes, if unprivileged user wants to send audit message, he should ask privileged user to setup the audit_backlog_limit for him. I know it's a little of hack, but I don't have good idea :( There's a recent patch that actually clarifies the way audit_backlog_limit works, since different parts of the code seemed to think different things. It now means unlimited, since there are other places to shut off logging. audit: allow unlimited backlog queue Yep, thanks for your information, we can set a negative number to backlog_limit to mark there is no available buff for this audit ns. At first, I'd say each audit_ns should be able to set its own audit_backlog_limit. The most obvious argument against this would be the vulnerability of a DoS. There are two problem we should conside, auditns costs lot's of memory by setting large backlog_limit and costs lot's of cpu resources by generating audit log all the time. So I think the privileged user should have the ability to limit the backlog len. And I think it's not very necessary to keep on allowing auditns to set its own audit_backlog_limit. if you think this is necessary, we can add a field max_backlog_limit for per audit namespace. and set this value when we create auditns. And seem like the audit_rate_limit should not be change by unprivileged user. I don't know if I really follow your request... Could there be some automatic metrics to set sub audit_ns backlog limits, such as default to the same as init_audit_ns and have the init_audit_ns override those defaults? Could this be done per user like ulimiit? I think something like ulimit cannot help us. we should set sub-auditns's backlog_limit in parent auditns.. so maybe the proc file is the best way. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 13/12/09, Gao feng wrote: > On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: > > Quoting Gao feng (gaof...@cn.fujitsu.com): > >> The main target of this patchset is allowing user in audit > >> namespace to generate the USER_MSG type of audit message, > >> some userspace tools need to generate audit message, or > >> these tools will broken. > >> > >> And the login process in container may want to setup > >> /proc//loginuid, right now this value is unalterable > >> once it being set. this will also broke the login problem > >> in container. After this patchset, we can reset this loginuid > >> to zero if task is running in a new audit namespace. > >> > >> Same with v1 patchset, in this patchset, only the privileged > >> user in init_audit_ns and init_user_ns has rights to > >> add/del audit rules. and these rules are gloabl. all > >> audit namespace will comply with the rules. > >> > >> Compared with v1, v2 patch has some big changes. > >> 1, the audit namespace is not assigned to user namespace. > >>since there is no available bit of flags for clone, we > >>create audit namespace through netlink, patch[18/20] > >>introduces a new audit netlink type AUDIT_CREATE_NS. > >>the privileged user in userns has rights to create a > >>audit namespace, it means the unprivileged user can > >>create auditns through create userns first. In order > >>to prevent them from doing harm to host, the default > >>audit_backlog_limit of un-init-audit-ns is zero(means > >>audit is unavailable in audit namespace). and it can't > >>be changed in auditns through netlink. > > > > So the unprivileged user can create an audit-ns, but can't > > then actually send any messages there? I guess setting it > > to something small would just be hacky? > > Yes, if unprivileged user wants to send audit message, he should > ask privileged user to setup the audit_backlog_limit for him. > > I know it's a little of hack, but I don't have good idea :( There's a recent patch that actually clarifies the way audit_backlog_limit works, since different parts of the code seemed to think different things. It now means unlimited, since there are other places to shut off logging. audit: allow unlimited backlog queue At first, I'd say each audit_ns should be able to set its own audit_backlog_limit. The most obvious argument against this would be the vulnerability of a DoS. Could there be some automatic metrics to set sub audit_ns backlog limits, such as default to the same as init_audit_ns and have the init_audit_ns override those defaults? Could this be done per user like ulimiit? - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 13/12/09, Gao feng wrote: On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. So the unprivileged user can create an audit-ns, but can't then actually send any messages there? I guess setting it to something small would just be hacky? Yes, if unprivileged user wants to send audit message, he should ask privileged user to setup the audit_backlog_limit for him. I know it's a little of hack, but I don't have good idea :( There's a recent patch that actually clarifies the way audit_backlog_limit works, since different parts of the code seemed to think different things. It now means unlimited, since there are other places to shut off logging. audit: allow unlimited backlog queue At first, I'd say each audit_ns should be able to set its own audit_backlog_limit. The most obvious argument against this would be the vulnerability of a DoS. Could there be some automatic metrics to set sub audit_ns backlog limits, such as default to the same as init_audit_ns and have the init_audit_ns override those defaults? Could this be done per user like ulimiit? - RGB -- Richard Guy Briggs rbri...@redhat.com Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): > On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: > > Quoting Eric Paris (epa...@redhat.com): > >> On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: > >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > On 12/10/2013 02:26 AM, Serge Hallyn wrote: > > Quoting Gao feng (gaof...@cn.fujitsu.com): > >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > Hi > > On 10/24/2013 03:31 PM, Gao feng wrote: > > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > > > The main target of this patchset is allowing user in audit > > namespace to generate the USER_MSG type of audit message, > > some userspace tools need to generate audit message, or > > these tools will broken. > > > > I really need this feature, right now,some process such as > logind are broken in container becase we leak of this feature. > >>> > >>> Your set doesn't address loginuid though right? How exactly do you > >>> expect to do that? If user violates MAC policy and audit msg is > >>> sent to init user ns by mac subsys, you need the loginuid from > >>> init_audit_ns. where will that be stored if you allow updates > >>> of loginuid in auditns? > >>> > >> This patchset doesn't include the loginuid part. > >> > >> the loginuid is stored in task as before. > >> In my opinion, when task creates a new audit namespace, this task's > >> loginuid will be reset to zero, so the children tasks can set their > >> loginuid. Does this change break the MAC? > > > > I think so, yes. In an LSPP selinux environment, if the task > > manages to trigger an selinux deny rule which is audited, then > > the loginuid must make sense on the host. Now presumably it > > will get translated to the mapped host uid, and we can figure > > out the host uid owning it through /etc/subuid. But that adds > > /etc/subuid as a new part of the TCB without any warning > > So in that sense, for LSPP, it breaks it. > > > > Looks like my opinion is incorrect. > > In the audit-next tree, Eric added a new audit feature to allow > privileged > user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE > is disabled, the privileged user can reset/set the loginuid of task. I > think this way is safe since only privileged user can do the change. > > So I will not change the loginuid part. > > Thanks for your information Serge :) > >>> > >>> Unfortunately this makes the patchset much less compelling :) The > >>> problem I was looking into is that a container running in a user > >>> namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not > >>> capable(CAP_AUDIT_*)) set loginuids at all. > >>> > >>> Which from an LSPP pov is correct; which is why I was hoping you were > >>> going to have the audit namespaces be hierarchical, with a task in a > >>> level 2 audit ns having two loginuids - one in his own auditns, and > >>> one in the initial one. > >> > >> Right now user namespace + audit is just total crud. We all know > >> this... (I'm not sure pid is must better, but I digress) All thoughts > >> around loginuid in the kernel right this very moment only make sense in > >> the initial user namespace and all permission checks are in the initial > >> user namespace as well. > >> > >> I think I'm a proponent of the hierarchical approach to audit > >> namespaces. An audit namespace would hold a reference to the > >> pid/user/whatever namespace it was created in/with. Each audit > >> namespace should have it's own set of filter rules, etc. Instead of > >> just storing 'loginuid' we store 'loginuid+user namespace'. When the > > > > So long as the kernel stores the kuid_t (which the only sane thing to > > do) that is a non-issue. > > > >> kernel creates a record it should translate the loginuid to the > >> namespace of the audit namespace and send the record. > > > > Yup, that should go without saying. Use kuid_t in kernel and translate > > at the kernel-user boundary. > > > > I can implement audit namespace as a hierarchy, give per auditns a level value > and a pointer which point to parent auditns. > > but for the loginuid part, I think we can implement it after we push the audit > ns into the upstream. > > Is this ok? Well as I"ve said the loginuid part is the only one that interests me. I'll be out most of the rest of the year, but I'll review any patchset you send for what seems to me to be correctness :) > >> It's a pretty major rewrite, but at least it makes sense. Things like > >> AVC's might show up in multiple audit logs, but in every log they would > >> make sense to the admin of that namespace... > >> > >> But what the hell do I know... > > > > Exactly how it would all affect
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the So long as the kernel stores the kuid_t (which the only sane thing to do) that is a non-issue. kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. Yup, that should go without saying. Use kuid_t in kernel and translate at the kernel-user boundary. I can implement audit namespace as a hierarchy, give per auditns a level value and a pointer which point to parent auditns. but for the loginuid part, I think we can implement it after we push the audit ns into the upstream. Is this ok? Well as Ive said the loginuid part is the only one that interests me. I'll be out most of the rest of the year, but I'll review any patchset you send for what seems to me to be correctness :) It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know... Exactly how it would all affect selinux. I'm happy it seems we agree. This idea looks good to me, I will Investigate this. :) Thanks. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: > Quoting Eric Paris (epa...@redhat.com): >> On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: >>> Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: >>> Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. >>> >>> Your set doesn't address loginuid though right? How exactly do you >>> expect to do that? If user violates MAC policy and audit msg is >>> sent to init user ns by mac subsys, you need the loginuid from >>> init_audit_ns. where will that be stored if you allow updates >>> of loginuid in auditns? >>> >> This patchset doesn't include the loginuid part. >> >> the loginuid is stored in task as before. >> In my opinion, when task creates a new audit namespace, this task's >> loginuid will be reset to zero, so the children tasks can set their >> loginuid. Does this change break the MAC? > > I think so, yes. In an LSPP selinux environment, if the task > manages to trigger an selinux deny rule which is audited, then > the loginuid must make sense on the host. Now presumably it > will get translated to the mapped host uid, and we can figure > out the host uid owning it through /etc/subuid. But that adds > /etc/subuid as a new part of the TCB without any warning > So in that sense, for LSPP, it breaks it. > Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) >>> >>> Unfortunately this makes the patchset much less compelling :) The >>> problem I was looking into is that a container running in a user >>> namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not >>> capable(CAP_AUDIT_*)) set loginuids at all. >>> >>> Which from an LSPP pov is correct; which is why I was hoping you were >>> going to have the audit namespaces be hierarchical, with a task in a >>> level 2 audit ns having two loginuids - one in his own auditns, and >>> one in the initial one. >> >> Right now user namespace + audit is just total crud. We all know >> this... (I'm not sure pid is must better, but I digress) All thoughts >> around loginuid in the kernel right this very moment only make sense in >> the initial user namespace and all permission checks are in the initial >> user namespace as well. >> >> I think I'm a proponent of the hierarchical approach to audit >> namespaces. An audit namespace would hold a reference to the >> pid/user/whatever namespace it was created in/with. Each audit >> namespace should have it's own set of filter rules, etc. Instead of >> just storing 'loginuid' we store 'loginuid+user namespace'. When the > > So long as the kernel stores the kuid_t (which the only sane thing to > do) that is a non-issue. > >> kernel creates a record it should translate the loginuid to the >> namespace of the audit namespace and send the record. > > Yup, that should go without saying. Use kuid_t in kernel and translate > at the kernel-user boundary. > I can implement audit namespace as a hierarchy, give per auditns a level value and a pointer which point to parent auditns. but for the loginuid part, I think we can implement it after we push the audit ns into the upstream. Is this ok? >> It's a pretty major rewrite, but at least it makes sense. Things like >> AVC's might show up in multiple audit logs, but in every log they would >> make sense to the admin of that namespace... >> >> But what the hell do I know... > > Exactly how it would all affect selinux. I'm happy it seems we agree. This idea looks good to me, I will Investigate this. :) Thanks. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/11/2013 04:36 AM, Serge E. Hallyn wrote: Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the So long as the kernel stores the kuid_t (which the only sane thing to do) that is a non-issue. kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. Yup, that should go without saying. Use kuid_t in kernel and translate at the kernel-user boundary. I can implement audit namespace as a hierarchy, give per auditns a level value and a pointer which point to parent auditns. but for the loginuid part, I think we can implement it after we push the audit ns into the upstream. Is this ok? It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know... Exactly how it would all affect selinux. I'm happy it seems we agree. This idea looks good to me, I will Investigate this. :) Thanks. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Eric Paris (epa...@redhat.com): > On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: > > Quoting Gao feng (gaof...@cn.fujitsu.com): > > > On 12/10/2013 02:26 AM, Serge Hallyn wrote: > > > > Quoting Gao feng (gaof...@cn.fujitsu.com): > > > >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > > > >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > > > Hi > > > > > > On 10/24/2013 03:31 PM, Gao feng wrote: > > > > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > > > > > > > The main target of this patchset is allowing user in audit > > > > namespace to generate the USER_MSG type of audit message, > > > > some userspace tools need to generate audit message, or > > > > these tools will broken. > > > > > > > > > > I really need this feature, right now,some process such as > > > logind are broken in container becase we leak of this feature. > > > >>> > > > >>> Your set doesn't address loginuid though right? How exactly do you > > > >>> expect to do that? If user violates MAC policy and audit msg is > > > >>> sent to init user ns by mac subsys, you need the loginuid from > > > >>> init_audit_ns. where will that be stored if you allow updates > > > >>> of loginuid in auditns? > > > >>> > > > >> This patchset doesn't include the loginuid part. > > > >> > > > >> the loginuid is stored in task as before. > > > >> In my opinion, when task creates a new audit namespace, this task's > > > >> loginuid will be reset to zero, so the children tasks can set their > > > >> loginuid. Does this change break the MAC? > > > > > > > > I think so, yes. In an LSPP selinux environment, if the task > > > > manages to trigger an selinux deny rule which is audited, then > > > > the loginuid must make sense on the host. Now presumably it > > > > will get translated to the mapped host uid, and we can figure > > > > out the host uid owning it through /etc/subuid. But that adds > > > > /etc/subuid as a new part of the TCB without any warning > > > > So in that sense, for LSPP, it breaks it. > > > > > > > > > > Looks like my opinion is incorrect. > > > > > > In the audit-next tree, Eric added a new audit feature to allow privileged > > > user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE > > > is disabled, the privileged user can reset/set the loginuid of task. I > > > think this way is safe since only privileged user can do the change. > > > > > > So I will not change the loginuid part. > > > > > > Thanks for your information Serge :) > > > > Unfortunately this makes the patchset much less compelling :) The > > problem I was looking into is that a container running in a user > > namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not > > capable(CAP_AUDIT_*)) set loginuids at all. > > > > Which from an LSPP pov is correct; which is why I was hoping you were > > going to have the audit namespaces be hierarchical, with a task in a > > level 2 audit ns having two loginuids - one in his own auditns, and > > one in the initial one. > > Right now user namespace + audit is just total crud. We all know > this... (I'm not sure pid is must better, but I digress) All thoughts > around loginuid in the kernel right this very moment only make sense in > the initial user namespace and all permission checks are in the initial > user namespace as well. > > I think I'm a proponent of the hierarchical approach to audit > namespaces. An audit namespace would hold a reference to the > pid/user/whatever namespace it was created in/with. Each audit > namespace should have it's own set of filter rules, etc. Instead of > just storing 'loginuid' we store 'loginuid+user namespace'. When the So long as the kernel stores the kuid_t (which the only sane thing to do) that is a non-issue. > kernel creates a record it should translate the loginuid to the > namespace of the audit namespace and send the record. Yup, that should go without saying. Use kuid_t in kernel and translate at the kernel-user boundary. > It's a pretty major rewrite, but at least it makes sense. Things like > AVC's might show up in multiple audit logs, but in every log they would > make sense to the admin of that namespace... > > But what the hell do I know... Exactly how it would all affect selinux. I'm happy it seems we agree. > Namespaces scare me... -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): > > On 12/10/2013 02:26 AM, Serge Hallyn wrote: > > > Quoting Gao feng (gaof...@cn.fujitsu.com): > > >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > > >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > > Hi > > > > On 10/24/2013 03:31 PM, Gao feng wrote: > > > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > > > > > The main target of this patchset is allowing user in audit > > > namespace to generate the USER_MSG type of audit message, > > > some userspace tools need to generate audit message, or > > > these tools will broken. > > > > > > > I really need this feature, right now,some process such as > > logind are broken in container becase we leak of this feature. > > >>> > > >>> Your set doesn't address loginuid though right? How exactly do you > > >>> expect to do that? If user violates MAC policy and audit msg is > > >>> sent to init user ns by mac subsys, you need the loginuid from > > >>> init_audit_ns. where will that be stored if you allow updates > > >>> of loginuid in auditns? > > >>> > > >> This patchset doesn't include the loginuid part. > > >> > > >> the loginuid is stored in task as before. > > >> In my opinion, when task creates a new audit namespace, this task's > > >> loginuid will be reset to zero, so the children tasks can set their > > >> loginuid. Does this change break the MAC? > > > > > > I think so, yes. In an LSPP selinux environment, if the task > > > manages to trigger an selinux deny rule which is audited, then > > > the loginuid must make sense on the host. Now presumably it > > > will get translated to the mapped host uid, and we can figure > > > out the host uid owning it through /etc/subuid. But that adds > > > /etc/subuid as a new part of the TCB without any warning > > > So in that sense, for LSPP, it breaks it. > > > > > > > Looks like my opinion is incorrect. > > > > In the audit-next tree, Eric added a new audit feature to allow privileged > > user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE > > is disabled, the privileged user can reset/set the loginuid of task. I > > think this way is safe since only privileged user can do the change. > > > > So I will not change the loginuid part. > > > > Thanks for your information Serge :) > > Unfortunately this makes the patchset much less compelling :) The > problem I was looking into is that a container running in a user > namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not > capable(CAP_AUDIT_*)) set loginuids at all. > > Which from an LSPP pov is correct; which is why I was hoping you were > going to have the audit namespaces be hierarchical, with a task in a > level 2 audit ns having two loginuids - one in his own auditns, and > one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know... Namespaces scare me... -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): > On 12/10/2013 02:26 AM, Serge Hallyn wrote: > > Quoting Gao feng (gaof...@cn.fujitsu.com): > >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > >>> Quoting Gao feng (gaof...@cn.fujitsu.com): > Hi > > On 10/24/2013 03:31 PM, Gao feng wrote: > > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > > > The main target of this patchset is allowing user in audit > > namespace to generate the USER_MSG type of audit message, > > some userspace tools need to generate audit message, or > > these tools will broken. > > > > I really need this feature, right now,some process such as > logind are broken in container becase we leak of this feature. > >>> > >>> Your set doesn't address loginuid though right? How exactly do you > >>> expect to do that? If user violates MAC policy and audit msg is > >>> sent to init user ns by mac subsys, you need the loginuid from > >>> init_audit_ns. where will that be stored if you allow updates > >>> of loginuid in auditns? > >>> > >> This patchset doesn't include the loginuid part. > >> > >> the loginuid is stored in task as before. > >> In my opinion, when task creates a new audit namespace, this task's > >> loginuid will be reset to zero, so the children tasks can set their > >> loginuid. Does this change break the MAC? > > > > I think so, yes. In an LSPP selinux environment, if the task > > manages to trigger an selinux deny rule which is audited, then > > the loginuid must make sense on the host. Now presumably it > > will get translated to the mapped host uid, and we can figure > > out the host uid owning it through /etc/subuid. But that adds > > /etc/subuid as a new part of the TCB without any warning > > So in that sense, for LSPP, it breaks it. > > > > Looks like my opinion is incorrect. > > In the audit-next tree, Eric added a new audit feature to allow privileged > user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE > is disabled, the privileged user can reset/set the loginuid of task. I > think this way is safe since only privileged user can do the change. > > So I will not change the loginuid part. > > Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/10/2013 02:26 AM, Serge Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: >>> Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. >>> >>> Your set doesn't address loginuid though right? How exactly do you >>> expect to do that? If user violates MAC policy and audit msg is >>> sent to init user ns by mac subsys, you need the loginuid from >>> init_audit_ns. where will that be stored if you allow updates >>> of loginuid in auditns? >>> >> This patchset doesn't include the loginuid part. >> >> the loginuid is stored in task as before. >> In my opinion, when task creates a new audit namespace, this task's >> loginuid will be reset to zero, so the children tasks can set their >> loginuid. Does this change break the MAC? > > I think so, yes. In an LSPP selinux environment, if the task > manages to trigger an selinux deny rule which is audited, then > the loginuid must make sense on the host. Now presumably it > will get translated to the mapped host uid, and we can figure > out the host uid owning it through /etc/subuid. But that adds > /etc/subuid as a new part of the TCB without any warning > So in that sense, for LSPP, it breaks it. > Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know... Namespaces scare me... -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Eric Paris (epa...@redhat.com): On Tue, 2013-12-10 at 10:51 -0600, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. Right now user namespace + audit is just total crud. We all know this... (I'm not sure pid is must better, but I digress) All thoughts around loginuid in the kernel right this very moment only make sense in the initial user namespace and all permission checks are in the initial user namespace as well. I think I'm a proponent of the hierarchical approach to audit namespaces. An audit namespace would hold a reference to the pid/user/whatever namespace it was created in/with. Each audit namespace should have it's own set of filter rules, etc. Instead of just storing 'loginuid' we store 'loginuid+user namespace'. When the So long as the kernel stores the kuid_t (which the only sane thing to do) that is a non-issue. kernel creates a record it should translate the loginuid to the namespace of the audit namespace and send the record. Yup, that should go without saying. Use kuid_t in kernel and translate at the kernel-user boundary. It's a pretty major rewrite, but at least it makes sense. Things like AVC's might show up in multiple audit logs, but in every log they would make sense to the admin of that namespace... But what the hell do I know... Exactly how it would all affect selinux. I'm happy it seems we agree. Namespaces scare me... -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/10/2013 02:26 AM, Serge Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. Looks like my opinion is incorrect. In the audit-next tree, Eric added a new audit feature to allow privileged user to disable AUDIT_LOGINUID_IMMUTABLE. after AUDIT_LOGINUID_IMMUTABLE is disabled, the privileged user can reset/set the loginuid of task. I think this way is safe since only privileged user can do the change. So I will not change the loginuid part. Thanks for your information Serge :) Unfortunately this makes the patchset much less compelling :) The problem I was looking into is that a container running in a user namespace cannot (bc he has ns_capable(CAP_AUDIT_*) but not capable(CAP_AUDIT_*)) set loginuids at all. Which from an LSPP pov is correct; which is why I was hoping you were going to have the audit namespaces be hierarchical, with a task in a level 2 audit ns having two loginuids - one in his own auditns, and one in the initial one. -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): > On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > > Quoting Gao feng (gaof...@cn.fujitsu.com): > >> Hi > >> > >> On 10/24/2013 03:31 PM, Gao feng wrote: > >>> Here is the v1 patchset: http://lwn.net/Articles/549546/ > >>> > >>> The main target of this patchset is allowing user in audit > >>> namespace to generate the USER_MSG type of audit message, > >>> some userspace tools need to generate audit message, or > >>> these tools will broken. > >>> > >> > >> I really need this feature, right now,some process such as > >> logind are broken in container becase we leak of this feature. > > > > Your set doesn't address loginuid though right? How exactly do you > > expect to do that? If user violates MAC policy and audit msg is > > sent to init user ns by mac subsys, you need the loginuid from > > init_audit_ns. where will that be stored if you allow updates > > of loginuid in auditns? > > > This patchset doesn't include the loginuid part. > > the loginuid is stored in task as before. > In my opinion, when task creates a new audit namespace, this task's > loginuid will be reset to zero, so the children tasks can set their > loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning So in that sense, for LSPP, it breaks it. -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? I think so, yes. In an LSPP selinux environment, if the task manages to trigger an selinux deny rule which is audited, then the loginuid must make sense on the host. Now presumably it will get translated to the mapped host uid, and we can figure out the host uid owning it through /etc/subuid. But that adds /etc/subuid as a new part of the TCB without any warning shrug So in that sense, for LSPP, it breaks it. -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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi Serge, Thanks for your comments! On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> Here is the v1 patchset: http://lwn.net/Articles/549546/ >> >> The main target of this patchset is allowing user in audit >> namespace to generate the USER_MSG type of audit message, >> some userspace tools need to generate audit message, or >> these tools will broken. >> >> And the login process in container may want to setup >> /proc//loginuid, right now this value is unalterable >> once it being set. this will also broke the login problem >> in container. After this patchset, we can reset this loginuid >> to zero if task is running in a new audit namespace. >> >> Same with v1 patchset, in this patchset, only the privileged >> user in init_audit_ns and init_user_ns has rights to >> add/del audit rules. and these rules are gloabl. all >> audit namespace will comply with the rules. >> >> Compared with v1, v2 patch has some big changes. >> 1, the audit namespace is not assigned to user namespace. >>since there is no available bit of flags for clone, we >>create audit namespace through netlink, patch[18/20] >>introduces a new audit netlink type AUDIT_CREATE_NS. >>the privileged user in userns has rights to create a >>audit namespace, it means the unprivileged user can >>create auditns through create userns first. In order >>to prevent them from doing harm to host, the default >>audit_backlog_limit of un-init-audit-ns is zero(means >>audit is unavailable in audit namespace). and it can't >>be changed in auditns through netlink. > > So the unprivileged user can create an audit-ns, but can't > then actually send any messages there? I guess setting it > to something small would just be hacky? Yes, if unprivileged user wants to send audit message, he should ask privileged user to setup the audit_backlog_limit for him. I know it's a little of hack, but I don't have good idea :( -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: > Quoting Gao feng (gaof...@cn.fujitsu.com): >> Hi >> >> On 10/24/2013 03:31 PM, Gao feng wrote: >>> Here is the v1 patchset: http://lwn.net/Articles/549546/ >>> >>> The main target of this patchset is allowing user in audit >>> namespace to generate the USER_MSG type of audit message, >>> some userspace tools need to generate audit message, or >>> these tools will broken. >>> >> >> I really need this feature, right now,some process such as >> logind are broken in container becase we leak of this feature. > > Your set doesn't address loginuid though right? How exactly do you > expect to do that? If user violates MAC policy and audit msg is > sent to init user ns by mac subsys, you need the loginuid from > init_audit_ns. where will that be stored if you allow updates > of loginuid in auditns? > This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? Thanks! -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 12/07/2013 06:12 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? This patchset doesn't include the loginuid part. the loginuid is stored in task as before. In my opinion, when task creates a new audit namespace, this task's loginuid will be reset to zero, so the children tasks can set their loginuid. Does this change break the MAC? Thanks! -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi Serge, Thanks for your comments! On 12/07/2013 05:31 AM, Serge E. Hallyn wrote: Quoting Gao feng (gaof...@cn.fujitsu.com): Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. So the unprivileged user can create an audit-ns, but can't then actually send any messages there? I guess setting it to something small would just be hacky? Yes, if unprivileged user wants to send audit message, he should ask privileged user to setup the audit_backlog_limit for him. I know it's a little of hack, but I don't have good idea :( -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): > Hi > > On 10/24/2013 03:31 PM, Gao feng wrote: > > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > > > The main target of this patchset is allowing user in audit > > namespace to generate the USER_MSG type of audit message, > > some userspace tools need to generate audit message, or > > these tools will broken. > > > > I really need this feature, right now,some process such as > logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > > And the login process in container may want to setup > /proc//loginuid, right now this value is unalterable > once it being set. this will also broke the login problem > in container. After this patchset, we can reset this loginuid > to zero if task is running in a new audit namespace. > > Same with v1 patchset, in this patchset, only the privileged > user in init_audit_ns and init_user_ns has rights to > add/del audit rules. and these rules are gloabl. all > audit namespace will comply with the rules. > > Compared with v1, v2 patch has some big changes. > 1, the audit namespace is not assigned to user namespace. >since there is no available bit of flags for clone, we >create audit namespace through netlink, patch[18/20] >introduces a new audit netlink type AUDIT_CREATE_NS. >the privileged user in userns has rights to create a >audit namespace, it means the unprivileged user can >create auditns through create userns first. In order >to prevent them from doing harm to host, the default >audit_backlog_limit of un-init-audit-ns is zero(means >audit is unavailable in audit namespace). and it can't >be changed in auditns through netlink. So the unprivileged user can create an audit-ns, but can't then actually send any messages there? I guess setting it to something small would just be hacky? -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. So the unprivileged user can create an audit-ns, but can't then actually send any messages there? I guess setting it to something small would just be hacky? -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Quoting Gao feng (gaof...@cn.fujitsu.com): Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. Your set doesn't address loginuid though right? How exactly do you expect to do that? If user violates MAC policy and audit msg is sent to init user ns by mac subsys, you need the loginuid from init_audit_ns. where will that be stored if you allow updates of loginuid in auditns? -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi On 10/24/2013 03:31 PM, Gao feng wrote: > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. > And the login process in container may want to setup > /proc//loginuid, right now this value is unalterable > once it being set. this will also broke the login problem > in container. After this patchset, we can reset this loginuid > to zero if task is running in a new audit namespace. > I notice this problem has been fixed in audit tree, so may be I don't need to clean up loginuid when we create audit namespace. And in audit tree, audit socket is per net namespace, hmm, I want to know if anybody has a solution to allow processes to generate USER_MSG type of audit message in un init pid/user namepsace. Any idea? Eric,Steve,Richard? 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. I really need this feature, right now,some process such as logind are broken in container becase we leak of this feature. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. I notice this problem has been fixed in audit tree, so may be I don't need to clean up loginuid when we create audit namespace. And in audit tree, audit socket is per net namespace, hmm, I want to know if anybody has a solution to allow processes to generate USER_MSG type of audit message in un init pid/user namepsace. Any idea? Eric,Steve,Richard? 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/06/2013 03:14 AM, Richard Guy Briggs wrote: > On Tue, Nov 05, 2013 at 04:56:55PM +0800, Gao feng wrote: >> On 11/05/2013 04:11 PM, Li Zefan wrote: >>> On 2013/11/5 15:52, Gao feng wrote: On 11/05/2013 03:51 PM, Gao feng wrote: > Ping... I want to catch up the merge window.. >>> >>> Even if your patches are accepted by a certain maintainer immediately, >>> he will in no doubt queue them for 3.14. >> >> Yes, you are right... >> But I still want to get some comments.. > > Definitely won't make it in in this merge window. I agree it needs > discussion, but I won't start that for at least another week (I'm > currently at IETF in Vancouver.). > Get it,hope we can start discussion ASAP. Thanks -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/06/2013 03:14 AM, Richard Guy Briggs wrote: On Tue, Nov 05, 2013 at 04:56:55PM +0800, Gao feng wrote: On 11/05/2013 04:11 PM, Li Zefan wrote: On 2013/11/5 15:52, Gao feng wrote: On 11/05/2013 03:51 PM, Gao feng wrote: Ping... I want to catch up the merge window.. Even if your patches are accepted by a certain maintainer immediately, he will in no doubt queue them for 3.14. Yes, you are right... But I still want to get some comments.. Definitely won't make it in in this merge window. I agree it needs discussion, but I won't start that for at least another week (I'm currently at IETF in Vancouver.). Get it,hope we can start discussion ASAP. Thanks -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On Tue, Nov 05, 2013 at 04:56:55PM +0800, Gao feng wrote: > On 11/05/2013 04:11 PM, Li Zefan wrote: > > On 2013/11/5 15:52, Gao feng wrote: > >> On 11/05/2013 03:51 PM, Gao feng wrote: > >>> Ping... > >> > >> I want to catch up the merge window.. > > > > Even if your patches are accepted by a certain maintainer immediately, > > he will in no doubt queue them for 3.14. > > Yes, you are right... > But I still want to get some comments.. Definitely won't make it in in this merge window. I agree it needs discussion, but I won't start that for at least another week (I'm currently at IETF in Vancouver.). - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/05/2013 04:11 PM, Li Zefan wrote: > On 2013/11/5 15:52, Gao feng wrote: >> On 11/05/2013 03:51 PM, Gao feng wrote: >>> Ping... >>> >> >> I want to catch up the merge window.. >> > > Even if your patches are accepted by a certain maintainer immediately, > he will in no doubt queue them for 3.14. > Yes, you are right... But I still want to get some comments.. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 2013/11/5 15:52, Gao feng wrote: > On 11/05/2013 03:51 PM, Gao feng wrote: >> Ping... >> > > I want to catch up the merge window.. > Even if your patches are accepted by a certain maintainer immediately, he will in no doubt queue them for 3.14. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 2013/11/5 15:52, Gao feng wrote: On 11/05/2013 03:51 PM, Gao feng wrote: Ping... I want to catch up the merge window.. Even if your patches are accepted by a certain maintainer immediately, he will in no doubt queue them for 3.14. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/05/2013 04:11 PM, Li Zefan wrote: On 2013/11/5 15:52, Gao feng wrote: On 11/05/2013 03:51 PM, Gao feng wrote: Ping... I want to catch up the merge window.. Even if your patches are accepted by a certain maintainer immediately, he will in no doubt queue them for 3.14. Yes, you are right... But I still want to get some comments.. -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On Tue, Nov 05, 2013 at 04:56:55PM +0800, Gao feng wrote: On 11/05/2013 04:11 PM, Li Zefan wrote: On 2013/11/5 15:52, Gao feng wrote: On 11/05/2013 03:51 PM, Gao feng wrote: Ping... I want to catch up the merge window.. Even if your patches are accepted by a certain maintainer immediately, he will in no doubt queue them for 3.14. Yes, you are right... But I still want to get some comments.. Definitely won't make it in in this merge window. I agree it needs discussion, but I won't start that for at least another week (I'm currently at IETF in Vancouver.). - RGB -- Richard Guy Briggs rbri...@redhat.com Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- 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: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/05/2013 03:51 PM, Gao feng wrote: > Ping... > I want to catch up the merge window.. > On 10/31/2013 11:52 AM, Gao feng wrote: >> Hi Eric Paris, >> >> Can you give me some comments? >> >> You think the tying audit namespace to user namespace is a bad idea, >> so this patchset doesn't assign auditns to userns and introduce an >> new audit netlink type to help to create audit namespace. >> >> and this patchset also introduces an new proc interface to make >> sure container can't influence the whole system. >> >> and the audit rules are not namespace aware, all of audit namespaces >> should comply with the rules. in next step, if we find it's need to >> make audit rules per audit namespace, then it's the time to do that >> job. >> >> This patchset also makes all of net namespaces have ability to send/ >> receive audit netlink message. >> >> I may miss some points, if you find there are some shortage or loophole, >> please let me know. >> >> Thanks! >> >> On 10/24/2013 03:31 PM, Gao feng wrote: >>> Here is the v1 patchset: http://lwn.net/Articles/549546/ >>> >>> The main target of this patchset is allowing user in audit >>> namespace to generate the USER_MSG type of audit message, >>> some userspace tools need to generate audit message, or >>> these tools will broken. >>> >>> And the login process in container may want to setup >>> /proc//loginuid, right now this value is unalterable >>> once it being set. this will also broke the login problem >>> in container. After this patchset, we can reset this loginuid >>> to zero if task is running in a new audit namespace. >>> >>> Same with v1 patchset, in this patchset, only the privileged >>> user in init_audit_ns and init_user_ns has rights to >>> add/del audit rules. and these rules are gloabl. all >>> audit namespace will comply with the rules. >>> >>> Compared with v1, v2 patch has some big changes. >>> 1, the audit namespace is not assigned to user namespace. >>>since there is no available bit of flags for clone, we >>>create audit namespace through netlink, patch[18/20] >>>introduces a new audit netlink type AUDIT_CREATE_NS. >>>the privileged user in userns has rights to create a >>>audit namespace, it means the unprivileged user can >>>create auditns through create userns first. In order >>>to prevent them from doing harm to host, the default >>>audit_backlog_limit of un-init-audit-ns is zero(means >>>audit is unavailable in audit namespace). and it can't >>>be changed in auditns through netlink. >>> >>> 2, introduce /proc//audit_log_limit >>>this interface is used to setup log_limit of audit >>>namespace. we need this interface to make audit >>>available in un-init-audit-ns. Only the privileged user >>>has right to set this value, it means only the root user >>>of host can change it. >>> >>> 3, make audit namespace don't depend on net namespace. >>>patch[1/20] add a compare function audit_compare for >>>audit netlink, it always return true, it means the >>>netlink subsystem will find out the netlink socket >>>only through portid and netlink type. So we needn't >>>to create kernel side audit netlink socket for per >>>net namespace, all userspace audit netlink socket >>>can find out the audit_sock, and audit_sock can >>>communicate with them through the proper portid. >>>it's just like the behavior we don't have net >>>namespace before. >>> >>> >>> This patchset still need some work, such as allow changing >>> audit_enabled in audit namespace, auditd wants this feature. >>> >>> I send this patchset now in order to get more comments, so >>> I can keep on improving namespace support for audit. >>> >>> Gao feng (20): >>> Audit: make audit netlink socket net namespace unaware >>> audit: introduce configure option CONFIG_AUDIT_NS >>> audit: make audit_skb_queue per audit namespace >>> audit: make audit_skb_hold_queue per audit namespace >>> audit: make audit_pid per audit namespace >>> audit: make kauditd_task per audit namespace >>> aduit: make audit_nlk_portid per audit namespace >>> audit: make kaudit_wait queue per audit namespace >>> audit: make audit_backlog_wait per audit namespace >>> audit: allow un-init audit ns to change pid and portid only >>> audit: use proper audit namespace in audit_receive_msg >>> audit: use proper audit_namespace in kauditd_thread >>> audit: introduce new audit logging interface for audit namespace >>> audit: pass proper audit namespace to audit_log_common_recv_msg >>> audit: Log audit pid config change in audit namespace >>> audit: allow GET,SET,USER MSG operations in audit namespace >>> nsproxy: don't make create_new_namespaces static >>> audit: add new message type AUDIT_CREATE_NS >>> audit: make audit_backlog_limit per audit namespace >>> audit: introduce /proc//audit_backlog_limit >>> >>> fs/proc/base.c | 53 ++ >>> include/linux/audit.h | 26 ++-
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Ping... On 10/31/2013 11:52 AM, Gao feng wrote: > Hi Eric Paris, > > Can you give me some comments? > > You think the tying audit namespace to user namespace is a bad idea, > so this patchset doesn't assign auditns to userns and introduce an > new audit netlink type to help to create audit namespace. > > and this patchset also introduces an new proc interface to make > sure container can't influence the whole system. > > and the audit rules are not namespace aware, all of audit namespaces > should comply with the rules. in next step, if we find it's need to > make audit rules per audit namespace, then it's the time to do that > job. > > This patchset also makes all of net namespaces have ability to send/ > receive audit netlink message. > > I may miss some points, if you find there are some shortage or loophole, > please let me know. > > Thanks! > > On 10/24/2013 03:31 PM, Gao feng wrote: >> Here is the v1 patchset: http://lwn.net/Articles/549546/ >> >> The main target of this patchset is allowing user in audit >> namespace to generate the USER_MSG type of audit message, >> some userspace tools need to generate audit message, or >> these tools will broken. >> >> And the login process in container may want to setup >> /proc//loginuid, right now this value is unalterable >> once it being set. this will also broke the login problem >> in container. After this patchset, we can reset this loginuid >> to zero if task is running in a new audit namespace. >> >> Same with v1 patchset, in this patchset, only the privileged >> user in init_audit_ns and init_user_ns has rights to >> add/del audit rules. and these rules are gloabl. all >> audit namespace will comply with the rules. >> >> Compared with v1, v2 patch has some big changes. >> 1, the audit namespace is not assigned to user namespace. >>since there is no available bit of flags for clone, we >>create audit namespace through netlink, patch[18/20] >>introduces a new audit netlink type AUDIT_CREATE_NS. >>the privileged user in userns has rights to create a >>audit namespace, it means the unprivileged user can >>create auditns through create userns first. In order >>to prevent them from doing harm to host, the default >>audit_backlog_limit of un-init-audit-ns is zero(means >>audit is unavailable in audit namespace). and it can't >>be changed in auditns through netlink. >> >> 2, introduce /proc//audit_log_limit >>this interface is used to setup log_limit of audit >>namespace. we need this interface to make audit >>available in un-init-audit-ns. Only the privileged user >>has right to set this value, it means only the root user >>of host can change it. >> >> 3, make audit namespace don't depend on net namespace. >>patch[1/20] add a compare function audit_compare for >>audit netlink, it always return true, it means the >>netlink subsystem will find out the netlink socket >>only through portid and netlink type. So we needn't >>to create kernel side audit netlink socket for per >>net namespace, all userspace audit netlink socket >>can find out the audit_sock, and audit_sock can >>communicate with them through the proper portid. >>it's just like the behavior we don't have net >>namespace before. >> >> >> This patchset still need some work, such as allow changing >> audit_enabled in audit namespace, auditd wants this feature. >> >> I send this patchset now in order to get more comments, so >> I can keep on improving namespace support for audit. >> >> Gao feng (20): >> Audit: make audit netlink socket net namespace unaware >> audit: introduce configure option CONFIG_AUDIT_NS >> audit: make audit_skb_queue per audit namespace >> audit: make audit_skb_hold_queue per audit namespace >> audit: make audit_pid per audit namespace >> audit: make kauditd_task per audit namespace >> aduit: make audit_nlk_portid per audit namespace >> audit: make kaudit_wait queue per audit namespace >> audit: make audit_backlog_wait per audit namespace >> audit: allow un-init audit ns to change pid and portid only >> audit: use proper audit namespace in audit_receive_msg >> audit: use proper audit_namespace in kauditd_thread >> audit: introduce new audit logging interface for audit namespace >> audit: pass proper audit namespace to audit_log_common_recv_msg >> audit: Log audit pid config change in audit namespace >> audit: allow GET,SET,USER MSG operations in audit namespace >> nsproxy: don't make create_new_namespaces static >> audit: add new message type AUDIT_CREATE_NS >> audit: make audit_backlog_limit per audit namespace >> audit: introduce /proc//audit_backlog_limit >> >> fs/proc/base.c | 53 ++ >> include/linux/audit.h | 26 ++- >> include/linux/audit_namespace.h | 92 ++ >> include/linux/nsproxy.h | 15 +- >> include/uapi/linux/audit.h | 1 + >> init/Kconfig| 10
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Ping... On 10/31/2013 11:52 AM, Gao feng wrote: Hi Eric Paris, Can you give me some comments? You think the tying audit namespace to user namespace is a bad idea, so this patchset doesn't assign auditns to userns and introduce an new audit netlink type to help to create audit namespace. and this patchset also introduces an new proc interface to make sure container can't influence the whole system. and the audit rules are not namespace aware, all of audit namespaces should comply with the rules. in next step, if we find it's need to make audit rules per audit namespace, then it's the time to do that job. This patchset also makes all of net namespaces have ability to send/ receive audit netlink message. I may miss some points, if you find there are some shortage or loophole, please let me know. Thanks! On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. 2, introduce /proc/pid/audit_log_limit this interface is used to setup log_limit of audit namespace. we need this interface to make audit available in un-init-audit-ns. Only the privileged user has right to set this value, it means only the root user of host can change it. 3, make audit namespace don't depend on net namespace. patch[1/20] add a compare function audit_compare for audit netlink, it always return true, it means the netlink subsystem will find out the netlink socket only through portid and netlink type. So we needn't to create kernel side audit netlink socket for per net namespace, all userspace audit netlink socket can find out the audit_sock, and audit_sock can communicate with them through the proper portid. it's just like the behavior we don't have net namespace before. This patchset still need some work, such as allow changing audit_enabled in audit namespace, auditd wants this feature. I send this patchset now in order to get more comments, so I can keep on improving namespace support for audit. Gao feng (20): Audit: make audit netlink socket net namespace unaware audit: introduce configure option CONFIG_AUDIT_NS audit: make audit_skb_queue per audit namespace audit: make audit_skb_hold_queue per audit namespace audit: make audit_pid per audit namespace audit: make kauditd_task per audit namespace aduit: make audit_nlk_portid per audit namespace audit: make kaudit_wait queue per audit namespace audit: make audit_backlog_wait per audit namespace audit: allow un-init audit ns to change pid and portid only audit: use proper audit namespace in audit_receive_msg audit: use proper audit_namespace in kauditd_thread audit: introduce new audit logging interface for audit namespace audit: pass proper audit namespace to audit_log_common_recv_msg audit: Log audit pid config change in audit namespace audit: allow GET,SET,USER MSG operations in audit namespace nsproxy: don't make create_new_namespaces static audit: add new message type AUDIT_CREATE_NS audit: make audit_backlog_limit per audit namespace audit: introduce /proc/pid/audit_backlog_limit fs/proc/base.c | 53 ++ include/linux/audit.h | 26 ++- include/linux/audit_namespace.h | 92 ++ include/linux/nsproxy.h | 15 +- include/uapi/linux/audit.h | 1 + init/Kconfig| 10 ++ kernel/Makefile | 2 +- kernel/audit.c | 364 +--- kernel/audit.h | 5 +-
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
On 11/05/2013 03:51 PM, Gao feng wrote: Ping... I want to catch up the merge window.. On 10/31/2013 11:52 AM, Gao feng wrote: Hi Eric Paris, Can you give me some comments? You think the tying audit namespace to user namespace is a bad idea, so this patchset doesn't assign auditns to userns and introduce an new audit netlink type to help to create audit namespace. and this patchset also introduces an new proc interface to make sure container can't influence the whole system. and the audit rules are not namespace aware, all of audit namespaces should comply with the rules. in next step, if we find it's need to make audit rules per audit namespace, then it's the time to do that job. This patchset also makes all of net namespaces have ability to send/ receive audit netlink message. I may miss some points, if you find there are some shortage or loophole, please let me know. Thanks! On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. 2, introduce /proc/pid/audit_log_limit this interface is used to setup log_limit of audit namespace. we need this interface to make audit available in un-init-audit-ns. Only the privileged user has right to set this value, it means only the root user of host can change it. 3, make audit namespace don't depend on net namespace. patch[1/20] add a compare function audit_compare for audit netlink, it always return true, it means the netlink subsystem will find out the netlink socket only through portid and netlink type. So we needn't to create kernel side audit netlink socket for per net namespace, all userspace audit netlink socket can find out the audit_sock, and audit_sock can communicate with them through the proper portid. it's just like the behavior we don't have net namespace before. This patchset still need some work, such as allow changing audit_enabled in audit namespace, auditd wants this feature. I send this patchset now in order to get more comments, so I can keep on improving namespace support for audit. Gao feng (20): Audit: make audit netlink socket net namespace unaware audit: introduce configure option CONFIG_AUDIT_NS audit: make audit_skb_queue per audit namespace audit: make audit_skb_hold_queue per audit namespace audit: make audit_pid per audit namespace audit: make kauditd_task per audit namespace aduit: make audit_nlk_portid per audit namespace audit: make kaudit_wait queue per audit namespace audit: make audit_backlog_wait per audit namespace audit: allow un-init audit ns to change pid and portid only audit: use proper audit namespace in audit_receive_msg audit: use proper audit_namespace in kauditd_thread audit: introduce new audit logging interface for audit namespace audit: pass proper audit namespace to audit_log_common_recv_msg audit: Log audit pid config change in audit namespace audit: allow GET,SET,USER MSG operations in audit namespace nsproxy: don't make create_new_namespaces static audit: add new message type AUDIT_CREATE_NS audit: make audit_backlog_limit per audit namespace audit: introduce /proc/pid/audit_backlog_limit fs/proc/base.c | 53 ++ include/linux/audit.h | 26 ++- include/linux/audit_namespace.h | 92 ++ include/linux/nsproxy.h | 15 +- include/uapi/linux/audit.h | 1 + init/Kconfig| 10 ++ kernel/Makefile | 2 +- kernel/audit.c | 364
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi Eric Paris, Can you give me some comments? You think the tying audit namespace to user namespace is a bad idea, so this patchset doesn't assign auditns to userns and introduce an new audit netlink type to help to create audit namespace. and this patchset also introduces an new proc interface to make sure container can't influence the whole system. and the audit rules are not namespace aware, all of audit namespaces should comply with the rules. in next step, if we find it's need to make audit rules per audit namespace, then it's the time to do that job. This patchset also makes all of net namespaces have ability to send/ receive audit netlink message. I may miss some points, if you find there are some shortage or loophole, please let me know. Thanks! On 10/24/2013 03:31 PM, Gao feng wrote: > Here is the v1 patchset: http://lwn.net/Articles/549546/ > > The main target of this patchset is allowing user in audit > namespace to generate the USER_MSG type of audit message, > some userspace tools need to generate audit message, or > these tools will broken. > > And the login process in container may want to setup > /proc//loginuid, right now this value is unalterable > once it being set. this will also broke the login problem > in container. After this patchset, we can reset this loginuid > to zero if task is running in a new audit namespace. > > Same with v1 patchset, in this patchset, only the privileged > user in init_audit_ns and init_user_ns has rights to > add/del audit rules. and these rules are gloabl. all > audit namespace will comply with the rules. > > Compared with v1, v2 patch has some big changes. > 1, the audit namespace is not assigned to user namespace. >since there is no available bit of flags for clone, we >create audit namespace through netlink, patch[18/20] >introduces a new audit netlink type AUDIT_CREATE_NS. >the privileged user in userns has rights to create a >audit namespace, it means the unprivileged user can >create auditns through create userns first. In order >to prevent them from doing harm to host, the default >audit_backlog_limit of un-init-audit-ns is zero(means >audit is unavailable in audit namespace). and it can't >be changed in auditns through netlink. > > 2, introduce /proc//audit_log_limit >this interface is used to setup log_limit of audit >namespace. we need this interface to make audit >available in un-init-audit-ns. Only the privileged user >has right to set this value, it means only the root user >of host can change it. > > 3, make audit namespace don't depend on net namespace. >patch[1/20] add a compare function audit_compare for >audit netlink, it always return true, it means the >netlink subsystem will find out the netlink socket >only through portid and netlink type. So we needn't >to create kernel side audit netlink socket for per >net namespace, all userspace audit netlink socket >can find out the audit_sock, and audit_sock can >communicate with them through the proper portid. >it's just like the behavior we don't have net >namespace before. > > > This patchset still need some work, such as allow changing > audit_enabled in audit namespace, auditd wants this feature. > > I send this patchset now in order to get more comments, so > I can keep on improving namespace support for audit. > > Gao feng (20): > Audit: make audit netlink socket net namespace unaware > audit: introduce configure option CONFIG_AUDIT_NS > audit: make audit_skb_queue per audit namespace > audit: make audit_skb_hold_queue per audit namespace > audit: make audit_pid per audit namespace > audit: make kauditd_task per audit namespace > aduit: make audit_nlk_portid per audit namespace > audit: make kaudit_wait queue per audit namespace > audit: make audit_backlog_wait per audit namespace > audit: allow un-init audit ns to change pid and portid only > audit: use proper audit namespace in audit_receive_msg > audit: use proper audit_namespace in kauditd_thread > audit: introduce new audit logging interface for audit namespace > audit: pass proper audit namespace to audit_log_common_recv_msg > audit: Log audit pid config change in audit namespace > audit: allow GET,SET,USER MSG operations in audit namespace > nsproxy: don't make create_new_namespaces static > audit: add new message type AUDIT_CREATE_NS > audit: make audit_backlog_limit per audit namespace > audit: introduce /proc//audit_backlog_limit > > fs/proc/base.c | 53 ++ > include/linux/audit.h | 26 ++- > include/linux/audit_namespace.h | 92 ++ > include/linux/nsproxy.h | 15 +- > include/uapi/linux/audit.h | 1 + > init/Kconfig| 10 ++ > kernel/Makefile | 2 +- > kernel/audit.c | 364 > +--- > kernel/audit.h | 5
Re: [RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Hi Eric Paris, Can you give me some comments? You think the tying audit namespace to user namespace is a bad idea, so this patchset doesn't assign auditns to userns and introduce an new audit netlink type to help to create audit namespace. and this patchset also introduces an new proc interface to make sure container can't influence the whole system. and the audit rules are not namespace aware, all of audit namespaces should comply with the rules. in next step, if we find it's need to make audit rules per audit namespace, then it's the time to do that job. This patchset also makes all of net namespaces have ability to send/ receive audit netlink message. I may miss some points, if you find there are some shortage or loophole, please let me know. Thanks! On 10/24/2013 03:31 PM, Gao feng wrote: Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. 2, introduce /proc/pid/audit_log_limit this interface is used to setup log_limit of audit namespace. we need this interface to make audit available in un-init-audit-ns. Only the privileged user has right to set this value, it means only the root user of host can change it. 3, make audit namespace don't depend on net namespace. patch[1/20] add a compare function audit_compare for audit netlink, it always return true, it means the netlink subsystem will find out the netlink socket only through portid and netlink type. So we needn't to create kernel side audit netlink socket for per net namespace, all userspace audit netlink socket can find out the audit_sock, and audit_sock can communicate with them through the proper portid. it's just like the behavior we don't have net namespace before. This patchset still need some work, such as allow changing audit_enabled in audit namespace, auditd wants this feature. I send this patchset now in order to get more comments, so I can keep on improving namespace support for audit. Gao feng (20): Audit: make audit netlink socket net namespace unaware audit: introduce configure option CONFIG_AUDIT_NS audit: make audit_skb_queue per audit namespace audit: make audit_skb_hold_queue per audit namespace audit: make audit_pid per audit namespace audit: make kauditd_task per audit namespace aduit: make audit_nlk_portid per audit namespace audit: make kaudit_wait queue per audit namespace audit: make audit_backlog_wait per audit namespace audit: allow un-init audit ns to change pid and portid only audit: use proper audit namespace in audit_receive_msg audit: use proper audit_namespace in kauditd_thread audit: introduce new audit logging interface for audit namespace audit: pass proper audit namespace to audit_log_common_recv_msg audit: Log audit pid config change in audit namespace audit: allow GET,SET,USER MSG operations in audit namespace nsproxy: don't make create_new_namespaces static audit: add new message type AUDIT_CREATE_NS audit: make audit_backlog_limit per audit namespace audit: introduce /proc/pid/audit_backlog_limit fs/proc/base.c | 53 ++ include/linux/audit.h | 26 ++- include/linux/audit_namespace.h | 92 ++ include/linux/nsproxy.h | 15 +- include/uapi/linux/audit.h | 1 + init/Kconfig| 10 ++ kernel/Makefile | 2 +- kernel/audit.c | 364 +--- kernel/audit.h | 5 +- kernel/audit_namespace.c| 123 ++ kernel/auditsc.c
[RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc//loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. 2, introduce /proc//audit_log_limit this interface is used to setup log_limit of audit namespace. we need this interface to make audit available in un-init-audit-ns. Only the privileged user has right to set this value, it means only the root user of host can change it. 3, make audit namespace don't depend on net namespace. patch[1/20] add a compare function audit_compare for audit netlink, it always return true, it means the netlink subsystem will find out the netlink socket only through portid and netlink type. So we needn't to create kernel side audit netlink socket for per net namespace, all userspace audit netlink socket can find out the audit_sock, and audit_sock can communicate with them through the proper portid. it's just like the behavior we don't have net namespace before. This patchset still need some work, such as allow changing audit_enabled in audit namespace, auditd wants this feature. I send this patchset now in order to get more comments, so I can keep on improving namespace support for audit. Gao feng (20): Audit: make audit netlink socket net namespace unaware audit: introduce configure option CONFIG_AUDIT_NS audit: make audit_skb_queue per audit namespace audit: make audit_skb_hold_queue per audit namespace audit: make audit_pid per audit namespace audit: make kauditd_task per audit namespace aduit: make audit_nlk_portid per audit namespace audit: make kaudit_wait queue per audit namespace audit: make audit_backlog_wait per audit namespace audit: allow un-init audit ns to change pid and portid only audit: use proper audit namespace in audit_receive_msg audit: use proper audit_namespace in kauditd_thread audit: introduce new audit logging interface for audit namespace audit: pass proper audit namespace to audit_log_common_recv_msg audit: Log audit pid config change in audit namespace audit: allow GET,SET,USER MSG operations in audit namespace nsproxy: don't make create_new_namespaces static audit: add new message type AUDIT_CREATE_NS audit: make audit_backlog_limit per audit namespace audit: introduce /proc//audit_backlog_limit fs/proc/base.c | 53 ++ include/linux/audit.h | 26 ++- include/linux/audit_namespace.h | 92 ++ include/linux/nsproxy.h | 15 +- include/uapi/linux/audit.h | 1 + init/Kconfig| 10 ++ kernel/Makefile | 2 +- kernel/audit.c | 364 +--- kernel/audit.h | 5 +- kernel/audit_namespace.c| 123 ++ kernel/auditsc.c| 6 +- kernel/nsproxy.c| 18 +- 12 files changed, 561 insertions(+), 154 deletions(-) create mode 100644 include/linux/audit_namespace.h create mode 100644 kernel/audit_namespace.c -- 1.8.3.1 -- 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/
[RFC Part1 PATCH 00/20 v2] Add namespace support for audit
Here is the v1 patchset: http://lwn.net/Articles/549546/ The main target of this patchset is allowing user in audit namespace to generate the USER_MSG type of audit message, some userspace tools need to generate audit message, or these tools will broken. And the login process in container may want to setup /proc/pid/loginuid, right now this value is unalterable once it being set. this will also broke the login problem in container. After this patchset, we can reset this loginuid to zero if task is running in a new audit namespace. Same with v1 patchset, in this patchset, only the privileged user in init_audit_ns and init_user_ns has rights to add/del audit rules. and these rules are gloabl. all audit namespace will comply with the rules. Compared with v1, v2 patch has some big changes. 1, the audit namespace is not assigned to user namespace. since there is no available bit of flags for clone, we create audit namespace through netlink, patch[18/20] introduces a new audit netlink type AUDIT_CREATE_NS. the privileged user in userns has rights to create a audit namespace, it means the unprivileged user can create auditns through create userns first. In order to prevent them from doing harm to host, the default audit_backlog_limit of un-init-audit-ns is zero(means audit is unavailable in audit namespace). and it can't be changed in auditns through netlink. 2, introduce /proc/pid/audit_log_limit this interface is used to setup log_limit of audit namespace. we need this interface to make audit available in un-init-audit-ns. Only the privileged user has right to set this value, it means only the root user of host can change it. 3, make audit namespace don't depend on net namespace. patch[1/20] add a compare function audit_compare for audit netlink, it always return true, it means the netlink subsystem will find out the netlink socket only through portid and netlink type. So we needn't to create kernel side audit netlink socket for per net namespace, all userspace audit netlink socket can find out the audit_sock, and audit_sock can communicate with them through the proper portid. it's just like the behavior we don't have net namespace before. This patchset still need some work, such as allow changing audit_enabled in audit namespace, auditd wants this feature. I send this patchset now in order to get more comments, so I can keep on improving namespace support for audit. Gao feng (20): Audit: make audit netlink socket net namespace unaware audit: introduce configure option CONFIG_AUDIT_NS audit: make audit_skb_queue per audit namespace audit: make audit_skb_hold_queue per audit namespace audit: make audit_pid per audit namespace audit: make kauditd_task per audit namespace aduit: make audit_nlk_portid per audit namespace audit: make kaudit_wait queue per audit namespace audit: make audit_backlog_wait per audit namespace audit: allow un-init audit ns to change pid and portid only audit: use proper audit namespace in audit_receive_msg audit: use proper audit_namespace in kauditd_thread audit: introduce new audit logging interface for audit namespace audit: pass proper audit namespace to audit_log_common_recv_msg audit: Log audit pid config change in audit namespace audit: allow GET,SET,USER MSG operations in audit namespace nsproxy: don't make create_new_namespaces static audit: add new message type AUDIT_CREATE_NS audit: make audit_backlog_limit per audit namespace audit: introduce /proc/pid/audit_backlog_limit fs/proc/base.c | 53 ++ include/linux/audit.h | 26 ++- include/linux/audit_namespace.h | 92 ++ include/linux/nsproxy.h | 15 +- include/uapi/linux/audit.h | 1 + init/Kconfig| 10 ++ kernel/Makefile | 2 +- kernel/audit.c | 364 +--- kernel/audit.h | 5 +- kernel/audit_namespace.c| 123 ++ kernel/auditsc.c| 6 +- kernel/nsproxy.c| 18 +- 12 files changed, 561 insertions(+), 154 deletions(-) create mode 100644 include/linux/audit_namespace.h create mode 100644 kernel/audit_namespace.c -- 1.8.3.1 -- 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/
