Re: [PATCH V3 0/6] namespaces: log namespaces per task
Le 20/08/2014 18:25, Richard Guy Briggs a écrit : On 14/08/19, Eric W. Biederman wrote: Richard Guy Briggs writes: On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc//ns/. Please see http://www.kernelhub.org/?p=2=477668 and in particular http://www.kernelhub.org/?msg=477678=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. I am reading a contradiction here: https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html and this posting went completely ignored: https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html And then there was this patchset and thread where there was some good discussion to clarify the use case: https://lkml.org/lkml/2014/4/22/662 Then V2: https://lkml.org/lkml/2014/5/9/637 Then V3 3 months ago: https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html I'm about to post another version of the patchset addressing Eric Paris' concerns about record types, field naming... I also try to find a solution to identify netns in userland to solve some network problems (see http://thread.gmane.org/gmane.linux.network/315933/focus=321753). This serial number solution may be reused for this. We really need to find a way to solve this. Regards, Nicolas -- 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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/08/19, Eric W. Biederman wrote: > Richard Guy Briggs writes: > > > On 14/05/20, Richard Guy Briggs wrote: > >> On 14/05/20, Eric Paris wrote: > >> > On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: > >> > > The purpose is to track namespaces in use by logged processes from the > >> > > perspective of init_*_ns. > > > > (Including the Linux API list due to the additions to /proc//ns/. > > Please see http://www.kernelhub.org/?p=2=477668 and in particular > > http://www.kernelhub.org/?msg=477678=2 ) > > Sigh if you have to use something like this use the proc inode > number. It is the same thing. > > I hate to claim it is unique absent of the proc superblock but it is and > will be for the forseable future. > > It would be better to include the block device number that appears in > proc of 3h of the primary mount of to qualify the number. But it is not > particularly important. Coming up with an additional unique number that > needs to be maintained seems stronlgy silly. I am reading a contradiction here: https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html and this posting went completely ignored: https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html And then there was this patchset and thread where there was some good discussion to clarify the use case: https://lkml.org/lkml/2014/4/22/662 Then V2: https://lkml.org/lkml/2014/5/9/637 Then V3 3 months ago: https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html I'm about to post another version of the patchset addressing Eric Paris' concerns about record types, field naming... > Eric > > > > > > >> > > 5/6 provides an example of usage for audit_log_task_info() which is > >> > > used by > >> > > syscall audits, among others. audit_log_task() and > >> > > audit_common_recv_message() > >> > > would be other potential use cases. > >> > > > >> > > Proposed output format: > >> > > This differs slightly from Aristeu's patch because of the label > >> > > conflict with > >> > > "pid=" due to including it in existing records rather than it being a > >> > > seperate > >> > > record. The serial numbers are printed in hex. > >> > >type=SYSCALL msg=audit(1399651071.433:72): arch=c03e > >> > > syscall=272 success=yes exit=0 a0=4000 a1= a2=0 > >> > > a3=22 items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 > >> > > fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 > >> > > comm="(t-daemon)" exe="/usr/lib/systemd/systemd" netns=97 utsns=2 > >> > > ipcns=1 pidns=4 userns=3 mntns=5 subj=system_u:system_r:init_t:s0 > >> > > key=(null) > >> > > >> > I'm undecided if I'd rather see this as a separate NS_INFO record type. > >> > It would mean we could filter them out of the logs... > >> > >> I don't have a strong opinion either way. Steve G.'s opinion would be > >> helpful here. > > > > Breaking this out into a seperate record type would mean calling > > audit_log_namespace_info() from the callers of audit_log_task_info() > > (presently audit_log_link_denied(), ima_audit_measurement(), > > audit_log_exit() ), but would make it easier to emit with other record > > types. > > > >> > Do we print out lots of pidns=0 for tasks not in a newly created NS? Do > >> > we want to? > >> > >> There is no "pidns=0", but I understand your point. This would come > >> back to Steve G.'s point about disappearing fields, and the value of > >> having it as a seperate record that could be filtered. > >> > >> > > 6/6 tracks the creation and deletion of of namespaces, listing the > >> > > type of > >> > > namespace instance, related namespace id if there is one and the newly > >> > > minted > >> > > serial number. > >> > > > >> > > Proposed output format: > >> > >type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 > >> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 > >> > > type=2 old_snum=0 snum=a1 res=1 > >> > > >> > I'd love to be able to grep for netns=20 and find both the NS_INIT and > >> > the SYSCALL/NS_INFO records, instead of having them named different > >> > things. So basically I think you want to translate the type= into a > >> > string for the old_X= and X=... > >> > >> That actually makes a bit more sense, and we could do away with the > >> "type=" field since the "Xns=" fields are self-describing. > > > > Steve, how do you feel about this since the NS_INIT/NS_DEL record type > > would have changing fields amongst the 6 namespace types. Only one of > > the 6 would be present in each message. I suppose we could have an > > NS_INIT_XXX/NS_DEL_XXX for each namespace type. > > > >> - RGB > > > > - 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 - RGB -- Richard Guy
Re: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/08/19, Eric W. Biederman wrote: Richard Guy Briggs r...@redhat.com writes: On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc/pid/ns/. Please see http://www.kernelhub.org/?p=2msg=477668 and in particular http://www.kernelhub.org/?msg=477678p=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. I am reading a contradiction here: https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html and this posting went completely ignored: https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html And then there was this patchset and thread where there was some good discussion to clarify the use case: https://lkml.org/lkml/2014/4/22/662 Then V2: https://lkml.org/lkml/2014/5/9/637 Then V3 3 months ago: https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html I'm about to post another version of the patchset addressing Eric Paris' concerns about record types, field naming... Eric snip 5/6 provides an example of usage for audit_log_task_info() which is used by syscall audits, among others. audit_log_task() and audit_common_recv_message() would be other potential use cases. Proposed output format: This differs slightly from Aristeu's patch because of the label conflict with pid= due to including it in existing records rather than it being a seperate record. The serial numbers are printed in hex. type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon) exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5 subj=system_u:system_r:init_t:s0 key=(null) I'm undecided if I'd rather see this as a separate NS_INFO record type. It would mean we could filter them out of the logs... I don't have a strong opinion either way. Steve G.'s opinion would be helpful here. Breaking this out into a seperate record type would mean calling audit_log_namespace_info() from the callers of audit_log_task_info() (presently audit_log_link_denied(), ima_audit_measurement(), audit_log_exit() ), but would make it easier to emit with other record types. Do we print out lots of pidns=0 for tasks not in a newly created NS? Do we want to? There is no pidns=0, but I understand your point. This would come back to Steve G.'s point about disappearing fields, and the value of having it as a seperate record that could be filtered. 6/6 tracks the creation and deletion of of namespaces, listing the type of namespace instance, related namespace id if there is one and the newly minted serial number. Proposed output format: type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2 old_snum=0 snum=a1 res=1 I'd love to be able to grep for netns=20 and find both the NS_INIT and the SYSCALL/NS_INFO records, instead of having them named different things. So basically I think you want to translate the type= into a string for the old_X= and X=... That actually makes a bit more sense, and we could do away with the type= field since the Xns= fields are self-describing. Steve, how do you feel about this since the NS_INIT/NS_DEL record type would have changing fields amongst the 6 namespace types. Only one of the 6 would be present in each message. I suppose we could have an NS_INIT_XXX/NS_DEL_XXX for each namespace type. - RGB - 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 - 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
Re: [PATCH V3 0/6] namespaces: log namespaces per task
Le 20/08/2014 18:25, Richard Guy Briggs a écrit : On 14/08/19, Eric W. Biederman wrote: Richard Guy Briggs r...@redhat.com writes: On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc/pid/ns/. Please see http://www.kernelhub.org/?p=2msg=477668 and in particular http://www.kernelhub.org/?msg=477678p=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. I am reading a contradiction here: https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html and this posting went completely ignored: https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html And then there was this patchset and thread where there was some good discussion to clarify the use case: https://lkml.org/lkml/2014/4/22/662 Then V2: https://lkml.org/lkml/2014/5/9/637 Then V3 3 months ago: https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html I'm about to post another version of the patchset addressing Eric Paris' concerns about record types, field naming... I also try to find a solution to identify netns in userland to solve some network problems (see http://thread.gmane.org/gmane.linux.network/315933/focus=321753). This serial number solution may be reused for this. We really need to find a way to solve this. Regards, Nicolas -- 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: [PATCH V3 0/6] namespaces: log namespaces per task
Richard Guy Briggs writes: > On 14/05/20, Richard Guy Briggs wrote: >> On 14/05/20, Eric Paris wrote: >> > On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: >> > > The purpose is to track namespaces in use by logged processes from the >> > > perspective of init_*_ns. > > (Including the Linux API list due to the additions to /proc//ns/. > Please see http://www.kernelhub.org/?p=2=477668 and in particular > http://www.kernelhub.org/?msg=477678=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. Eric > > >> > > 5/6 provides an example of usage for audit_log_task_info() which is used >> > > by >> > > syscall audits, among others. audit_log_task() and >> > > audit_common_recv_message() >> > > would be other potential use cases. >> > > >> > > Proposed output format: >> > > This differs slightly from Aristeu's patch because of the label conflict >> > > with >> > > "pid=" due to including it in existing records rather than it being a >> > > seperate >> > > record. The serial numbers are printed in hex. >> > > type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 >> > > success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 >> > > ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 >> > > sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" >> > > exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3 >> > > mntns=5 subj=system_u:system_r:init_t:s0 key=(null) >> > >> > I'm undecided if I'd rather see this as a separate NS_INFO record type. >> > It would mean we could filter them out of the logs... >> >> I don't have a strong opinion either way. Steve G.'s opinion would be >> helpful here. > > Breaking this out into a seperate record type would mean calling > audit_log_namespace_info() from the callers of audit_log_task_info() > (presently audit_log_link_denied(), ima_audit_measurement(), > audit_log_exit() ), but would make it easier to emit with other record > types. > >> > Do we print out lots of pidns=0 for tasks not in a newly created NS? Do >> > we want to? >> >> There is no "pidns=0", but I understand your point. This would come >> back to Steve G.'s point about disappearing fields, and the value of >> having it as a seperate record that could be filtered. >> >> > > 6/6 tracks the creation and deletion of of namespaces, listing the type >> > > of >> > > namespace instance, related namespace id if there is one and the newly >> > > minted >> > > serial number. >> > > >> > > Proposed output format: >> > > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 >> > > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 >> > > type=2 old_snum=0 snum=a1 res=1 >> > >> > I'd love to be able to grep for netns=20 and find both the NS_INIT and >> > the SYSCALL/NS_INFO records, instead of having them named different >> > things. So basically I think you want to translate the type= into a >> > string for the old_X= and X=... >> >> That actually makes a bit more sense, and we could do away with the >> "type=" field since the "Xns=" fields are self-describing. > > Steve, how do you feel about this since the NS_INIT/NS_DEL record type > would have changing fields amongst the 6 namespace types. Only one of > the 6 would be present in each message. I suppose we could have an > NS_INIT_XXX/NS_DEL_XXX for each namespace type. > >> - RGB > > - 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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/20, Richard Guy Briggs wrote: > On 14/05/20, Eric Paris wrote: > > On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: > > > The purpose is to track namespaces in use by logged processes from the > > > perspective of init_*_ns. (Including the Linux API list due to the additions to /proc//ns/. Please see http://www.kernelhub.org/?p=2=477668 and in particular http://www.kernelhub.org/?msg=477678=2 ) > > > 5/6 provides an example of usage for audit_log_task_info() which is used > > > by > > > syscall audits, among others. audit_log_task() and > > > audit_common_recv_message() > > > would be other potential use cases. > > > > > > Proposed output format: > > > This differs slightly from Aristeu's patch because of the label conflict > > > with > > > "pid=" due to including it in existing records rather than it being a > > > seperate > > > record. The serial numbers are printed in hex. > > > type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 > > > success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 > > > ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > > > sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)" > > > exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3 > > > mntns=5 subj=system_u:system_r:init_t:s0 key=(null) > > > > I'm undecided if I'd rather see this as a separate NS_INFO record type. > > It would mean we could filter them out of the logs... > > I don't have a strong opinion either way. Steve G.'s opinion would be > helpful here. Breaking this out into a seperate record type would mean calling audit_log_namespace_info() from the callers of audit_log_task_info() (presently audit_log_link_denied(), ima_audit_measurement(), audit_log_exit() ), but would make it easier to emit with other record types. > > Do we print out lots of pidns=0 for tasks not in a newly created NS? Do > > we want to? > > There is no "pidns=0", but I understand your point. This would come > back to Steve G.'s point about disappearing fields, and the value of > having it as a seperate record that could be filtered. > > > > 6/6 tracks the creation and deletion of of namespaces, listing the type of > > > namespace instance, related namespace id if there is one and the newly > > > minted > > > serial number. > > > > > > Proposed output format: > > > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 > > > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 > > > type=2 old_snum=0 snum=a1 res=1 > > > > I'd love to be able to grep for netns=20 and find both the NS_INIT and > > the SYSCALL/NS_INFO records, instead of having them named different > > things. So basically I think you want to translate the type= into a > > string for the old_X= and X=... > > That actually makes a bit more sense, and we could do away with the > "type=" field since the "Xns=" fields are self-describing. Steve, how do you feel about this since the NS_INIT/NS_DEL record type would have changing fields amongst the 6 namespace types. Only one of the 6 would be present in each message. I suppose we could have an NS_INIT_XXX/NS_DEL_XXX for each namespace type. > - RGB - 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: [PATCH V3 0/6] namespaces: log namespaces per task
Richard Guy Briggs r...@redhat.com writes: On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc/pid/ns/. Please see http://www.kernelhub.org/?p=2msg=477668 and in particular http://www.kernelhub.org/?msg=477678p=2 ) Sigh if you have to use something like this use the proc inode number. It is the same thing. I hate to claim it is unique absent of the proc superblock but it is and will be for the forseable future. It would be better to include the block device number that appears in proc of 3h of the primary mount of to qualify the number. But it is not particularly important. Coming up with an additional unique number that needs to be maintained seems stronlgy silly. Eric snip 5/6 provides an example of usage for audit_log_task_info() which is used by syscall audits, among others. audit_log_task() and audit_common_recv_message() would be other potential use cases. Proposed output format: This differs slightly from Aristeu's patch because of the label conflict with pid= due to including it in existing records rather than it being a seperate record. The serial numbers are printed in hex. type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon) exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5 subj=system_u:system_r:init_t:s0 key=(null) I'm undecided if I'd rather see this as a separate NS_INFO record type. It would mean we could filter them out of the logs... I don't have a strong opinion either way. Steve G.'s opinion would be helpful here. Breaking this out into a seperate record type would mean calling audit_log_namespace_info() from the callers of audit_log_task_info() (presently audit_log_link_denied(), ima_audit_measurement(), audit_log_exit() ), but would make it easier to emit with other record types. Do we print out lots of pidns=0 for tasks not in a newly created NS? Do we want to? There is no pidns=0, but I understand your point. This would come back to Steve G.'s point about disappearing fields, and the value of having it as a seperate record that could be filtered. 6/6 tracks the creation and deletion of of namespaces, listing the type of namespace instance, related namespace id if there is one and the newly minted serial number. Proposed output format: type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2 old_snum=0 snum=a1 res=1 I'd love to be able to grep for netns=20 and find both the NS_INIT and the SYSCALL/NS_INFO records, instead of having them named different things. So basically I think you want to translate the type= into a string for the old_X= and X=... That actually makes a bit more sense, and we could do away with the type= field since the Xns= fields are self-describing. Steve, how do you feel about this since the NS_INIT/NS_DEL record type would have changing fields amongst the 6 namespace types. Only one of the 6 would be present in each message. I suppose we could have an NS_INIT_XXX/NS_DEL_XXX for each namespace type. - RGB - 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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/20, Richard Guy Briggs wrote: On 14/05/20, Eric Paris wrote: On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote: The purpose is to track namespaces in use by logged processes from the perspective of init_*_ns. (Including the Linux API list due to the additions to /proc/pid/ns/. Please see http://www.kernelhub.org/?p=2msg=477668 and in particular http://www.kernelhub.org/?msg=477678p=2 ) snip 5/6 provides an example of usage for audit_log_task_info() which is used by syscall audits, among others. audit_log_task() and audit_common_recv_message() would be other potential use cases. Proposed output format: This differs slightly from Aristeu's patch because of the label conflict with pid= due to including it in existing records rather than it being a seperate record. The serial numbers are printed in hex. type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272 success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon) exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3 mntns=5 subj=system_u:system_r:init_t:s0 key=(null) I'm undecided if I'd rather see this as a separate NS_INFO record type. It would mean we could filter them out of the logs... I don't have a strong opinion either way. Steve G.'s opinion would be helpful here. Breaking this out into a seperate record type would mean calling audit_log_namespace_info() from the callers of audit_log_task_info() (presently audit_log_link_denied(), ima_audit_measurement(), audit_log_exit() ), but would make it easier to emit with other record types. Do we print out lots of pidns=0 for tasks not in a newly created NS? Do we want to? There is no pidns=0, but I understand your point. This would come back to Steve G.'s point about disappearing fields, and the value of having it as a seperate record that could be filtered. 6/6 tracks the creation and deletion of of namespaces, listing the type of namespace instance, related namespace id if there is one and the newly minted serial number. Proposed output format: type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2 old_snum=0 snum=a1 res=1 I'd love to be able to grep for netns=20 and find both the NS_INIT and the SYSCALL/NS_INFO records, instead of having them named different things. So basically I think you want to translate the type= into a string for the old_X= and X=... That actually makes a bit more sense, and we could do away with the type= field since the Xns= fields are self-describing. Steve, how do you feel about this since the NS_INIT/NS_DEL record type would have changing fields amongst the 6 namespace types. Only one of the 6 would be present in each message. I suppose we could have an NS_INIT_XXX/NS_DEL_XXX for each namespace type. - RGB - 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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/26, Michael Kerrisk (man-pages) wrote:
> Hi Richard
>
> On Mon, May 26, 2014 at 6:58 PM, Richard Guy Briggs wrote:
> > On 14/05/22, Michael Kerrisk wrote:
> >> Richard,
> >
> > Hi Michael,
> >
> >> On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs
> >> wrote:
> >> > The purpose is to track namespaces in use by logged processes from the
> >> > perspective of init_*_ns.
> >> >
> >> > 1/6 defines a function to generate them and assigns them.
> >> >
> >> > Use a serial number per namespace (unique across one boot of one kernel)
> >> > instead of the inode number (which is claimed to have had the right to
> >> > change
> >> > reserved and is not necessarily unique if there is more than one proc
> >> > fs). It
> >> > could be argued that the inode numbers have now become a defacto
> >> > interface and
> >> > can't change now, but I'm proposing this approach to see if this helps
> >> > address
> >> > some of the objections to the earlier patchset.
> >> >
> >> > 2/6 adds access functions to get to the serial numbers in a similar way
> >> > to
> >> > inode access for namespace proc operations.
> >> >
> >> > 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
> >> > available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose
> >> > "snum"
> >> > instead of "seq" for consistency with inum and there are a number of
> >> > other uses
> >> > of "seq" in the namespace code.
> >> >
> >> > 4/6 exposes proc's ns entries structure which lists a number of useful
> >> > operations per namespace type for other subsystems to use.
> >>
> >> Since the 3 and 4 change the ABI, please CC iterations of this patch
> >> series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
> >
> > Neither patch 3/6 nor 4/6 changes the syscall interface.
>
> (Agreed.)
>
> > Patch 3/6 adds /proc//ns/ entries, which looks more like #16 in
> > that document (for which /proc//ns/ was never added).
>
> But, that's a change to the surface that the kernel exposes to user
> space, right? If so, it is best CCed to linux-api.
Got it. Thanks!
> Thanks,
>
> Michael
- 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: [PATCH V3 0/6] namespaces: log namespaces per task
Hi Richard
On Mon, May 26, 2014 at 6:58 PM, Richard Guy Briggs wrote:
> On 14/05/22, Michael Kerrisk wrote:
>> Richard,
>
> Hi Michael,
>
>> On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs wrote:
>> > The purpose is to track namespaces in use by logged processes from the
>> > perspective of init_*_ns.
>> >
>> > 1/6 defines a function to generate them and assigns them.
>> >
>> > Use a serial number per namespace (unique across one boot of one kernel)
>> > instead of the inode number (which is claimed to have had the right to
>> > change
>> > reserved and is not necessarily unique if there is more than one proc fs).
>> > It
>> > could be argued that the inode numbers have now become a defacto interface
>> > and
>> > can't change now, but I'm proposing this approach to see if this helps
>> > address
>> > some of the objections to the earlier patchset.
>> >
>> > 2/6 adds access functions to get to the serial numbers in a similar way to
>> > inode access for namespace proc operations.
>> >
>> > 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
>> > available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
>> > instead of "seq" for consistency with inum and there are a number of other
>> > uses
>> > of "seq" in the namespace code.
>> >
>> > 4/6 exposes proc's ns entries structure which lists a number of useful
>> > operations per namespace type for other subsystems to use.
>>
>> Since the 3 and 4 change the ABI, please CC iterations of this patch
>> series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
>
> Neither patch 3/6 nor 4/6 changes the syscall interface.
(Agreed.)
> Patch 3/6 adds /proc//ns/ entries, which looks more like #16 in
> that document (for which /proc//ns/ was never added).
But, that's a change to the surface that the kernel exposes to user
space, right? If so, it is best CCed to linux-api.
Thanks,
Michael
--
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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/22, Michael Kerrisk wrote:
> Richard,
Hi Michael,
> On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs wrote:
> > The purpose is to track namespaces in use by logged processes from the
> > perspective of init_*_ns.
> >
> > 1/6 defines a function to generate them and assigns them.
> >
> > Use a serial number per namespace (unique across one boot of one kernel)
> > instead of the inode number (which is claimed to have had the right to
> > change
> > reserved and is not necessarily unique if there is more than one proc fs).
> > It
> > could be argued that the inode numbers have now become a defacto interface
> > and
> > can't change now, but I'm proposing this approach to see if this helps
> > address
> > some of the objections to the earlier patchset.
> >
> > 2/6 adds access functions to get to the serial numbers in a similar way to
> > inode access for namespace proc operations.
> >
> > 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
> > available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
> > instead of "seq" for consistency with inum and there are a number of other
> > uses
> > of "seq" in the namespace code.
> >
> > 4/6 exposes proc's ns entries structure which lists a number of useful
> > operations per namespace type for other subsystems to use.
>
> Since the 3 and 4 change the ABI, please CC iterations of this patch
> series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
Neither patch 3/6 nor 4/6 changes the syscall interface.
Patch 3/6 adds /proc//ns/ entries, which looks more like #16 in
that document (for which /proc//ns/ was never added).
Patch 4/6 adds internel kernel symbols which are never exposed to the
user.
Perhaps "expose" was the wrong word to use in the patch description.
This usage implies that it is no longer labelled "static" in its source
files to be able to expose that interface to other internal kernel
subsystems.
Ref:
SubmitChecklist (#16)
Documentation/stable_api_nonsense.txt
Documentation/ABI/README
> Michael
>
> > 5/6 provides an example of usage for audit_log_task_info() which is used by
> > syscall audits, among others. audit_log_task() and
> > audit_common_recv_message()
> > would be other potential use cases.
> >
> > Proposed output format:
> > This differs slightly from Aristeu's patch because of the label conflict
> > with
> > "pid=" due to including it in existing records rather than it being a
> > seperate
> > record. The serial numbers are printed in hex.
> > type=SYSCALL msg=audit(1399651071.433:72): arch=c03e
> > syscall=272 success=yes exit=0 a0=4000 a1= a2=0 a3=22
> > items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
> > egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)"
> > exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3
> > mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
> >
> > 6/6 tracks the creation and deletion of of namespaces, listing the type of
> > namespace instance, related namespace id if there is one and the newly
> > minted
> > serial number.
> >
> > Proposed output format:
> > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> > old_snum=0 snum=a1 res=1
> > type=NS_DEL msg=audit(1400217435.730:95): pid=524 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> > snum=a1 res=1
> >
> >
> > v2 -> v3:
> > Use atomic64_t in ns_serial to simplify it.
> > Avoid funciton duplication in proc, keying on dentry.
> > Squash down audit patch to avoid rcu sleep issues.
> > Add tracking for creation and deletion of namespace instances.
> >
> > v1 -> v2:
> > Avoid rollover by switching from an int to a long long.
> > Change rollover behaviour from simply avoiding zero to raising a
> > BUG.
> > Expose serial numbers in /proc//ns/*_snum.
> > Expose ns_entries and use it in audit.
> >
> >
> > Notes:
> > There has been some progress made for audit in net namespaces and pid
> > namespaces since this previous thread. net namespaces are now served as
> > peers
> > by one auditd in the init_net namespace with processes in a non-init_net
> > namespace being able to write records if they are in the init_user_ns and
> > have
> > CAP_AUDIT_WRITE. Processes in a non-init_pid_ns can now similarly write
> > records. As for CAP_AUDIT_READ, I just posted a patchset to check
> > capabilities
> > of userspace processes that try to join netlink broadcast groups.
> >
> > This set does not try to solve the non-init namespace audit messages and
> > auditd problem yet. That will come later, likely with additional auditd
> > instances running in another namespace with a limited ability to influence
> > the
> > master auditd. I echo Eric B's idea that
Re: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/22, Michael Kerrisk wrote:
Richard,
Hi Michael,
On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs r...@redhat.com wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to
change
reserved and is not necessarily unique if there is more than one proc fs).
It
could be argued that the inode numbers have now become a defacto interface
and
can't change now, but I'm proposing this approach to see if this helps
address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose snum
instead of seq for consistency with inum and there are a number of other
uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
Since the 3 and 4 change the ABI, please CC iterations of this patch
series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
Neither patch 3/6 nor 4/6 changes the syscall interface.
Patch 3/6 adds /proc/pid/ns/ entries, which looks more like #16 in
that document (for which /proc/pid/ns/nstype was never added).
Patch 4/6 adds internel kernel symbols which are never exposed to the
user.
Perhaps expose was the wrong word to use in the patch description.
This usage implies that it is no longer labelled static in its source
files to be able to expose that interface to other internal kernel
subsystems.
Ref:
SubmitChecklist (#16)
Documentation/stable_api_nonsense.txt
Documentation/ABI/README
Michael
5/6 provides an example of usage for audit_log_task_info() which is used by
syscall audits, among others. audit_log_task() and
audit_common_recv_message()
would be other potential use cases.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict
with
pid= due to including it in existing records rather than it being a
seperate
record. The serial numbers are printed in hex.
type=SYSCALL msg=audit(1399651071.433:72): arch=c03e
syscall=272 success=yes exit=0 a0=4000 a1= a2=0 a3=22
items=0 ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon)
exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3
mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
6/6 tracks the creation and deletion of of namespaces, listing the type of
namespace instance, related namespace id if there is one and the newly
minted
serial number.
Proposed output format:
type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
old_snum=0 snum=a1 res=1
type=NS_DEL msg=audit(1400217435.730:95): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
snum=a1 res=1
v2 - v3:
Use atomic64_t in ns_serial to simplify it.
Avoid funciton duplication in proc, keying on dentry.
Squash down audit patch to avoid rcu sleep issues.
Add tracking for creation and deletion of namespace instances.
v1 - v2:
Avoid rollover by switching from an int to a long long.
Change rollover behaviour from simply avoiding zero to raising a
BUG.
Expose serial numbers in /proc/pid/ns/*_snum.
Expose ns_entries and use it in audit.
Notes:
There has been some progress made for audit in net namespaces and pid
namespaces since this previous thread. net namespaces are now served as
peers
by one auditd in the init_net namespace with processes in a non-init_net
namespace being able to write records if they are in the init_user_ns and
have
CAP_AUDIT_WRITE. Processes in a non-init_pid_ns can now similarly write
records. As for CAP_AUDIT_READ, I just posted a patchset to check
capabilities
of userspace processes that try to join netlink broadcast groups.
This set does not try to solve the non-init namespace audit messages and
auditd problem yet. That will come later, likely with additional auditd
instances running in another namespace with a limited ability to influence
the
master auditd. I echo Eric B's idea that messages destined for different
namespaces would have to be tailored for that namespace with references that
make sense (such as the right pid number reported to that pid
Re: [PATCH V3 0/6] namespaces: log namespaces per task
Hi Richard
On Mon, May 26, 2014 at 6:58 PM, Richard Guy Briggs r...@redhat.com wrote:
On 14/05/22, Michael Kerrisk wrote:
Richard,
Hi Michael,
On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs r...@redhat.com wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to
change
reserved and is not necessarily unique if there is more than one proc fs).
It
could be argued that the inode numbers have now become a defacto interface
and
can't change now, but I'm proposing this approach to see if this helps
address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose snum
instead of seq for consistency with inum and there are a number of other
uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
Since the 3 and 4 change the ABI, please CC iterations of this patch
series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
Neither patch 3/6 nor 4/6 changes the syscall interface.
(Agreed.)
Patch 3/6 adds /proc/pid/ns/ entries, which looks more like #16 in
that document (for which /proc/pid/ns/nstype was never added).
But, that's a change to the surface that the kernel exposes to user
space, right? If so, it is best CCed to linux-api.
Thanks,
Michael
--
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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/26, Michael Kerrisk (man-pages) wrote:
Hi Richard
On Mon, May 26, 2014 at 6:58 PM, Richard Guy Briggs r...@redhat.com wrote:
On 14/05/22, Michael Kerrisk wrote:
Richard,
Hi Michael,
On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs r...@redhat.com
wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to
change
reserved and is not necessarily unique if there is more than one proc
fs). It
could be argued that the inode numbers have now become a defacto
interface and
can't change now, but I'm proposing this approach to see if this helps
address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way
to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose
snum
instead of seq for consistency with inum and there are a number of
other uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
Since the 3 and 4 change the ABI, please CC iterations of this patch
series to linux-...@vger.kernel.org, as per Documentation/SubmitChecklist.
Neither patch 3/6 nor 4/6 changes the syscall interface.
(Agreed.)
Patch 3/6 adds /proc/pid/ns/ entries, which looks more like #16 in
that document (for which /proc/pid/ns/nstype was never added).
But, that's a change to the surface that the kernel exposes to user
space, right? If so, it is best CCed to linux-api.
Got it. Thanks!
Thanks,
Michael
- 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: [PATCH V3 0/6] namespaces: log namespaces per task
Richard,
On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs wrote:
> The purpose is to track namespaces in use by logged processes from the
> perspective of init_*_ns.
>
> 1/6 defines a function to generate them and assigns them.
>
> Use a serial number per namespace (unique across one boot of one kernel)
> instead of the inode number (which is claimed to have had the right to change
> reserved and is not necessarily unique if there is more than one proc fs). It
> could be argued that the inode numbers have now become a defacto interface and
> can't change now, but I'm proposing this approach to see if this helps address
> some of the objections to the earlier patchset.
>
> 2/6 adds access functions to get to the serial numbers in a similar way to
> inode access for namespace proc operations.
>
> 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
> available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
> instead of "seq" for consistency with inum and there are a number of other
> uses
> of "seq" in the namespace code.
>
> 4/6 exposes proc's ns entries structure which lists a number of useful
> operations per namespace type for other subsystems to use.
Since the 3 and 4 change the ABI, please CC iterations of this patch
series to linux-...@vger.kernel.org, as per
Documentation/SubmitChecklist.
Cheers,
Michael
> 5/6 provides an example of usage for audit_log_task_info() which is used by
> syscall audits, among others. audit_log_task() and
> audit_common_recv_message()
> would be other potential use cases.
>
> Proposed output format:
> This differs slightly from Aristeu's patch because of the label conflict with
> "pid=" due to including it in existing records rather than it being a seperate
> record. The serial numbers are printed in hex.
> type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
> success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1
> pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)"
> exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3
> mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
>
> 6/6 tracks the creation and deletion of of namespaces, listing the type of
> namespace instance, related namespace id if there is one and the newly minted
> serial number.
>
> Proposed output format:
> type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> old_snum=0 snum=a1 res=1
> type=NS_DEL msg=audit(1400217435.730:95): pid=524 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> snum=a1 res=1
>
>
> v2 -> v3:
> Use atomic64_t in ns_serial to simplify it.
> Avoid funciton duplication in proc, keying on dentry.
> Squash down audit patch to avoid rcu sleep issues.
> Add tracking for creation and deletion of namespace instances.
>
> v1 -> v2:
> Avoid rollover by switching from an int to a long long.
> Change rollover behaviour from simply avoiding zero to raising a BUG.
> Expose serial numbers in /proc//ns/*_snum.
> Expose ns_entries and use it in audit.
>
>
> Notes:
> There has been some progress made for audit in net namespaces and pid
> namespaces since this previous thread. net namespaces are now served as peers
> by one auditd in the init_net namespace with processes in a non-init_net
> namespace being able to write records if they are in the init_user_ns and have
> CAP_AUDIT_WRITE. Processes in a non-init_pid_ns can now similarly write
> records. As for CAP_AUDIT_READ, I just posted a patchset to check
> capabilities
> of userspace processes that try to join netlink broadcast groups.
>
> This set does not try to solve the non-init namespace audit messages and
> auditd problem yet. That will come later, likely with additional auditd
> instances running in another namespace with a limited ability to influence the
> master auditd. I echo Eric B's idea that messages destined for different
> namespaces would have to be tailored for that namespace with references that
> make sense (such as the right pid number reported to that pid namespace, and
> not leaking info about parents or peers).
>
> Bugs:
> Patch 6/6 has a timing bug such that mnt and net namespace initial namespaces
> never get logged, I suspect because they are initialized before the audit
> subsystem. I've tried moving audit from __initcall to subsys_initcall, but
> that doesn't help.
>
> Questions:
> Is there a way to link serial numbers of namespaces involved in migration of a
> container to another kernel? It sounds like what is needed is a part of a
> mangement application that is able to pull the audit rcords from constituent
> hosts to build an audit trail of a container.
>
> What additional events should list this information?
>
Re: [PATCH V3 0/6] namespaces: log namespaces per task
Richard,
On Tue, May 20, 2014 at 3:12 PM, Richard Guy Briggs r...@redhat.com wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs). It
could be argued that the inode numbers have now become a defacto interface and
can't change now, but I'm proposing this approach to see if this helps address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose snum
instead of seq for consistency with inum and there are a number of other
uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
Since the 3 and 4 change the ABI, please CC iterations of this patch
series to linux-...@vger.kernel.org, as per
Documentation/SubmitChecklist.
Cheers,
Michael
5/6 provides an example of usage for audit_log_task_info() which is used by
syscall audits, among others. audit_log_task() and
audit_common_recv_message()
would be other potential use cases.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict with
pid= due to including it in existing records rather than it being a seperate
record. The serial numbers are printed in hex.
type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1
pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon)
exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3
mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
6/6 tracks the creation and deletion of of namespaces, listing the type of
namespace instance, related namespace id if there is one and the newly minted
serial number.
Proposed output format:
type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
old_snum=0 snum=a1 res=1
type=NS_DEL msg=audit(1400217435.730:95): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
snum=a1 res=1
v2 - v3:
Use atomic64_t in ns_serial to simplify it.
Avoid funciton duplication in proc, keying on dentry.
Squash down audit patch to avoid rcu sleep issues.
Add tracking for creation and deletion of namespace instances.
v1 - v2:
Avoid rollover by switching from an int to a long long.
Change rollover behaviour from simply avoiding zero to raising a BUG.
Expose serial numbers in /proc/pid/ns/*_snum.
Expose ns_entries and use it in audit.
Notes:
There has been some progress made for audit in net namespaces and pid
namespaces since this previous thread. net namespaces are now served as peers
by one auditd in the init_net namespace with processes in a non-init_net
namespace being able to write records if they are in the init_user_ns and have
CAP_AUDIT_WRITE. Processes in a non-init_pid_ns can now similarly write
records. As for CAP_AUDIT_READ, I just posted a patchset to check
capabilities
of userspace processes that try to join netlink broadcast groups.
This set does not try to solve the non-init namespace audit messages and
auditd problem yet. That will come later, likely with additional auditd
instances running in another namespace with a limited ability to influence the
master auditd. I echo Eric B's idea that messages destined for different
namespaces would have to be tailored for that namespace with references that
make sense (such as the right pid number reported to that pid namespace, and
not leaking info about parents or peers).
Bugs:
Patch 6/6 has a timing bug such that mnt and net namespace initial namespaces
never get logged, I suspect because they are initialized before the audit
subsystem. I've tried moving audit from __initcall to subsys_initcall, but
that doesn't help.
Questions:
Is there a way to link serial numbers of namespaces involved in migration of a
container to another kernel? It sounds like what is needed is a part of a
mangement application that is able to pull the audit rcords from constituent
hosts to build an audit trail of a container.
What additional events should list this information?
Does this present any problematic information leaks? Only CAP_AUDIT_CONTROL
(and proposed
Re: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/20, Eric Paris wrote:
> On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
> > The purpose is to track namespaces in use by logged processes from the
> > perspective of init_*_ns.
> >
> > 1/6 defines a function to generate them and assigns them.
> >
> > Use a serial number per namespace (unique across one boot of one kernel)
> > instead of the inode number (which is claimed to have had the right to
> > change
> > reserved and is not necessarily unique if there is more than one proc fs).
> > It
> > could be argued that the inode numbers have now become a defacto interface
> > and
> > can't change now, but I'm proposing this approach to see if this helps
> > address
> > some of the objections to the earlier patchset.
> >
> > 2/6 adds access functions to get to the serial numbers in a similar way to
> > inode access for namespace proc operations.
> >
> > 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
> > available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
> > instead of "seq" for consistency with inum and there are a number of other
> > uses
> > of "seq" in the namespace code.
> >
> > 4/6 exposes proc's ns entries structure which lists a number of useful
> > operations per namespace type for other subsystems to use.
> >
> > 5/6 provides an example of usage for audit_log_task_info() which is used by
> > syscall audits, among others. audit_log_task() and
> > audit_common_recv_message()
> > would be other potential use cases.
> >
> > Proposed output format:
> > This differs slightly from Aristeu's patch because of the label conflict
> > with
> > "pid=" due to including it in existing records rather than it being a
> > seperate
> > record. The serial numbers are printed in hex.
> > type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
> > success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0
> > ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> > sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)"
> > exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3
> > mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
>
> I'm undecided if I'd rather see this as a separate NS_INFO record type.
> It would mean we could filter them out of the logs...
I don't have a strong opinion either way. Steve G.'s opinion would be
helpful here.
> Do we print out lots of pidns=0 for tasks not in a newly created NS? Do
> we want to?
There is no "pidns=0", but I understand your point. This would come
back to Steve G.'s point about disappearing fields, and the value of
having it as a seperate record that could be filtered.
> > 6/6 tracks the creation and deletion of of namespaces, listing the type of
> > namespace instance, related namespace id if there is one and the newly
> > minted
> > serial number.
> >
> > Proposed output format:
> > type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
> > auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> > old_snum=0 snum=a1 res=1
>
> I'd love to be able to grep for netns=20 and find both the NS_INIT and
> the SYSCALL/NS_INFO records, instead of having them named different
> things. So basically I think you want to translate the type= into a
> string for the old_X= and X=...
That actually makes a bit more sense, and we could do away with the
"type=" field since the "Xns=" fields are self-describing.
Any hints on the timing issues mentioned in one of the notes? I'm
missing initial mntns and netns messages.
- 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: [PATCH V3 0/6] namespaces: log namespaces per task
On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
> The purpose is to track namespaces in use by logged processes from the
> perspective of init_*_ns.
>
> 1/6 defines a function to generate them and assigns them.
>
> Use a serial number per namespace (unique across one boot of one kernel)
> instead of the inode number (which is claimed to have had the right to change
> reserved and is not necessarily unique if there is more than one proc fs). It
> could be argued that the inode numbers have now become a defacto interface and
> can't change now, but I'm proposing this approach to see if this helps address
> some of the objections to the earlier patchset.
>
> 2/6 adds access functions to get to the serial numbers in a similar way to
> inode access for namespace proc operations.
>
> 3/6 implements, as suggested by Serge Hallyn, making these serial numbers
> available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose "snum"
> instead of "seq" for consistency with inum and there are a number of other
> uses
> of "seq" in the namespace code.
>
> 4/6 exposes proc's ns entries structure which lists a number of useful
> operations per namespace type for other subsystems to use.
>
> 5/6 provides an example of usage for audit_log_task_info() which is used by
> syscall audits, among others. audit_log_task() and
> audit_common_recv_message()
> would be other potential use cases.
>
> Proposed output format:
> This differs slightly from Aristeu's patch because of the label conflict with
> "pid=" due to including it in existing records rather than it being a seperate
> record. The serial numbers are printed in hex.
> type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
> success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1
> pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> fsgid=0 tty=(none) ses=4294967295 comm="(t-daemon)"
> exe="/usr/lib/systemd/systemd" netns=97 utsns=2 ipcns=1 pidns=4 userns=3
> mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
I'm undecided if I'd rather see this as a separate NS_INFO record type.
It would mean we could filter them out of the logs...
Do we print out lots of pidns=0 for tasks not in a newly created NS? Do
we want to?
> 6/6 tracks the creation and deletion of of namespaces, listing the type of
> namespace instance, related namespace id if there is one and the newly minted
> serial number.
>
> Proposed output format:
> type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
> auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
> old_snum=0 snum=a1 res=1
I'd love to be able to grep for netns=20 and find both the NS_INIT and
the SYSCALL/NS_INFO records, instead of having them named different
things. So basically I think you want to translate the type= into a
string for the old_X= and X=...
--
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: [PATCH V3 0/6] namespaces: log namespaces per task
On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to change
reserved and is not necessarily unique if there is more than one proc fs). It
could be argued that the inode numbers have now become a defacto interface and
can't change now, but I'm proposing this approach to see if this helps address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose snum
instead of seq for consistency with inum and there are a number of other
uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
5/6 provides an example of usage for audit_log_task_info() which is used by
syscall audits, among others. audit_log_task() and
audit_common_recv_message()
would be other potential use cases.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict with
pid= due to including it in existing records rather than it being a seperate
record. The serial numbers are printed in hex.
type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0 ppid=1
pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon)
exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3
mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
I'm undecided if I'd rather see this as a separate NS_INFO record type.
It would mean we could filter them out of the logs...
Do we print out lots of pidns=0 for tasks not in a newly created NS? Do
we want to?
6/6 tracks the creation and deletion of of namespaces, listing the type of
namespace instance, related namespace id if there is one and the newly minted
serial number.
Proposed output format:
type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
old_snum=0 snum=a1 res=1
I'd love to be able to grep for netns=20 and find both the NS_INIT and
the SYSCALL/NS_INFO records, instead of having them named different
things. So basically I think you want to translate the type= into a
string for the old_X= and X=...
--
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: [PATCH V3 0/6] namespaces: log namespaces per task
On 14/05/20, Eric Paris wrote:
On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
The purpose is to track namespaces in use by logged processes from the
perspective of init_*_ns.
1/6 defines a function to generate them and assigns them.
Use a serial number per namespace (unique across one boot of one kernel)
instead of the inode number (which is claimed to have had the right to
change
reserved and is not necessarily unique if there is more than one proc fs).
It
could be argued that the inode numbers have now become a defacto interface
and
can't change now, but I'm proposing this approach to see if this helps
address
some of the objections to the earlier patchset.
2/6 adds access functions to get to the serial numbers in a similar way to
inode access for namespace proc operations.
3/6 implements, as suggested by Serge Hallyn, making these serial numbers
available in /proc/self/ns/{ipc,mnt,net,pid,user,uts}_snum. I chose snum
instead of seq for consistency with inum and there are a number of other
uses
of seq in the namespace code.
4/6 exposes proc's ns entries structure which lists a number of useful
operations per namespace type for other subsystems to use.
5/6 provides an example of usage for audit_log_task_info() which is used by
syscall audits, among others. audit_log_task() and
audit_common_recv_message()
would be other potential use cases.
Proposed output format:
This differs slightly from Aristeu's patch because of the label conflict
with
pid= due to including it in existing records rather than it being a
seperate
record. The serial numbers are printed in hex.
type=SYSCALL msg=audit(1399651071.433:72): arch=c03e syscall=272
success=yes exit=0 a0=4000 a1= a2=0 a3=22 items=0
ppid=1 pid=483 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=(t-daemon)
exe=/usr/lib/systemd/systemd netns=97 utsns=2 ipcns=1 pidns=4 userns=3
mntns=5 subj=system_u:system_r:init_t:s0 key=(null)
I'm undecided if I'd rather see this as a separate NS_INFO record type.
It would mean we could filter them out of the logs...
I don't have a strong opinion either way. Steve G.'s opinion would be
helpful here.
Do we print out lots of pidns=0 for tasks not in a newly created NS? Do
we want to?
There is no pidns=0, but I understand your point. This would come
back to Steve G.'s point about disappearing fields, and the value of
having it as a seperate record that could be filtered.
6/6 tracks the creation and deletion of of namespaces, listing the type of
namespace instance, related namespace id if there is one and the newly
minted
serial number.
Proposed output format:
type=NS_INIT msg=audit(1400217435.706:94): pid=524 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:mount_t:s0 type=2
old_snum=0 snum=a1 res=1
I'd love to be able to grep for netns=20 and find both the NS_INIT and
the SYSCALL/NS_INFO records, instead of having them named different
things. So basically I think you want to translate the type= into a
string for the old_X= and X=...
That actually makes a bit more sense, and we could do away with the
type= field since the Xns= fields are self-describing.
Any hints on the timing issues mentioned in one of the notes? I'm
missing initial mntns and netns messages.
- 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/
