Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 2019-05-30 09:35, Paul Moore wrote: > On Thu, May 30, 2019 at 9:08 AM Steve Grubb wrote: > > On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote: > > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > > wrote: > > > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > > > Implement kernel audit container identifier. > > > > > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > > > good for inclusion? > > > > > > > > I haven't finished going through this latest revision, but unless > > > > Richard made any significant changes outside of the feedback from the > > > > v5 patchset I'm guessing we are "close". > > > > > > > > Based on discussions Richard and I had some time ago, I have always > > > > envisioned the plan as being get the kernel patchset, tests, docs > > > > ready (which Richard has been doing) and then run the actual > > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > > to make sure the actual implementation is sane from their perspective. > > > > They've already seen the design, so I'm not expecting any real > > > > surprises here, but sometimes opinions change when they have actual > > > > code in front of them to play with and review. > > > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > > whatever additional testing we can do would be a big win. I'm > > > > thinking I'll pull it into a separate branch in the audit tree > > > > (audit/working-container ?) and include that in my secnext kernels > > > > that I build/test on a regular basis; this is also a handy way to keep > > > > it based against the current audit/next branch. If any changes are > > > > needed Richard can either chose to base those changes on audit/next or > > > > the separate audit container ID branch; that's up to him. I've done > > > > this with other big changes in other trees, e.g. SELinux, and it has > > > > worked well to get some extra testing in and keep the patchset "merge > > > > ready" while others outside the subsystem look things over. > > > > > > I just sent my feedback on the v6 patchset, and it's small: basically > > > three patches with "one-liner" changes needed. > > > > > > Richard, it's your call on how you want to proceed from here. You can > > > post a v7 incorporating the feedback, or since the tweaks are so > > > minor, you can post fixup patches; the former being more > > > comprehensive, the later being quicker to review and digest. > > > Regardless of that, while we are waiting on a prototype from the > > > container folks, I think it would be good to pull this into a working > > > branch in the audit repo (as mentioned above), unless you would prefer > > > to keep it as a patchset on the mailing list? > > > > Personally, I'd like to see this on a branch so that it's easier to build a > > kernel locally for testing. > > FWIW, if Richard does prefer for me to pull it into a working branch I > plan to include it in my secnext builds both to make it easier to test > regularly and to make the changes available to people who don't want > to build their own kernel. Sure, let's do a working branch. I'll answer the issues in respective threads... > * http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html > > -- > paul moore > www.paul-moore.com > > -- > Linux-audit mailing list > Linux-audit@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Thu, May 30, 2019 at 9:08 AM Steve Grubb wrote: > On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > wrote: > > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > > Implement kernel audit container identifier. > > > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > > good for inclusion? > > > > > > I haven't finished going through this latest revision, but unless > > > Richard made any significant changes outside of the feedback from the > > > v5 patchset I'm guessing we are "close". > > > > > > Based on discussions Richard and I had some time ago, I have always > > > envisioned the plan as being get the kernel patchset, tests, docs > > > ready (which Richard has been doing) and then run the actual > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > to make sure the actual implementation is sane from their perspective. > > > They've already seen the design, so I'm not expecting any real > > > surprises here, but sometimes opinions change when they have actual > > > code in front of them to play with and review. > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > whatever additional testing we can do would be a big win. I'm > > > thinking I'll pull it into a separate branch in the audit tree > > > (audit/working-container ?) and include that in my secnext kernels > > > that I build/test on a regular basis; this is also a handy way to keep > > > it based against the current audit/next branch. If any changes are > > > needed Richard can either chose to base those changes on audit/next or > > > the separate audit container ID branch; that's up to him. I've done > > > this with other big changes in other trees, e.g. SELinux, and it has > > > worked well to get some extra testing in and keep the patchset "merge > > > ready" while others outside the subsystem look things over. > > > > I just sent my feedback on the v6 patchset, and it's small: basically > > three patches with "one-liner" changes needed. > > > > Richard, it's your call on how you want to proceed from here. You can > > post a v7 incorporating the feedback, or since the tweaks are so > > minor, you can post fixup patches; the former being more > > comprehensive, the later being quicker to review and digest. > > Regardless of that, while we are waiting on a prototype from the > > container folks, I think it would be good to pull this into a working > > branch in the audit repo (as mentioned above), unless you would prefer > > to keep it as a patchset on the mailing list? > > Personally, I'd like to see this on a branch so that it's easier to build a > kernel locally for testing. FWIW, if Richard does prefer for me to pull it into a working branch I plan to include it in my secnext builds both to make it easier to test regularly and to make the changes available to people who don't want to build their own kernel. * http://www.paul-moore.com/blog/d/2019/04/kernel_secnext_repo.html -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Wednesday, May 29, 2019 6:26:12 PM EDT Paul Moore wrote: > On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > > Implement kernel audit container identifier. > > > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we > > > good for inclusion? > > > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > I just sent my feedback on the v6 patchset, and it's small: basically > three patches with "one-liner" changes needed. > > Richard, it's your call on how you want to proceed from here. You can > post a v7 incorporating the feedback, or since the tweaks are so > minor, you can post fixup patches; the former being more > comprehensive, the later being quicker to review and digest. > Regardless of that, while we are waiting on a prototype from the > container folks, I think it would be good to pull this into a working > branch in the audit repo (as mentioned above), unless you would prefer > to keep it as a patchset on the mailing list? Personally, I'd like to see this on a branch so that it's easier to build a kernel locally for testing. -Steve > If you want to go with > the working branch approach, I'll keep the branch fresh and (re)based > against audit/next and if we notice any problems you can just submit > fixes against that branch (depending on the issue they can be fixup > patches, or proper patches). My hope is that this will enable the > process to move quicker as we get near the finish line.
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Mon, Apr 22, 2019 at 9:49 AM Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > Implement kernel audit container identifier. > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we good > > for > > inclusion? > > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. I just sent my feedback on the v6 patchset, and it's small: basically three patches with "one-liner" changes needed. Richard, it's your call on how you want to proceed from here. You can post a v7 incorporating the feedback, or since the tweaks are so minor, you can post fixup patches; the former being more comprehensive, the later being quicker to review and digest. Regardless of that, while we are waiting on a prototype from the container folks, I think it would be good to pull this into a working branch in the audit repo (as mentioned above), unless you would prefer to keep it as a patchset on the mailing list? If you want to go with the working branch approach, I'll keep the branch fresh and (re)based against audit/next and if we notice any problems you can just submit fixes against that branch (depending on the issue they can be fixup patches, or proper patches). My hope is that this will enable the process to move quicker as we get near the finish line. -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Wed, May 29, 2019 at 10:07 AM Daniel Walsh wrote: > On 5/29/19 9:17 AM, Paul Moore wrote: > > On Wed, May 29, 2019 at 8:03 AM Daniel Walsh wrote: > >> On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > >>> On 2019-05-28 19:00, Steve Grubb wrote: > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: > >> On 4/22/19 9:49 AM, Paul Moore wrote: > >>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > wrote: > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > Implement kernel audit container identifier. > I'm sorry, I've lost track of this, where have we landed on it? Are > we > good for inclusion? > >>> I haven't finished going through this latest revision, but unless > >>> Richard made any significant changes outside of the feedback from the > >>> v5 patchset I'm guessing we are "close". > >>> > >>> Based on discussions Richard and I had some time ago, I have always > >>> envisioned the plan as being get the kernel patchset, tests, docs > >>> ready (which Richard has been doing) and then run the actual > >>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., > >>> to make sure the actual implementation is sane from their perspective. > >>> They've already seen the design, so I'm not expecting any real > >>> surprises here, but sometimes opinions change when they have actual > >>> code in front of them to play with and review. > >>> > >>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, > >>> whatever additional testing we can do would be a big win. I'm > >>> thinking I'll pull it into a separate branch in the audit tree > >>> (audit/working-container ?) and include that in my secnext kernels > >>> that I build/test on a regular basis; this is also a handy way to keep > >>> it based against the current audit/next branch. If any changes are > >>> needed Richard can either chose to base those changes on audit/next or > >>> the separate audit container ID branch; that's up to him. I've done > >>> this with other big changes in other trees, e.g. SELinux, and it has > >>> worked well to get some extra testing in and keep the patchset "merge > >>> ready" while others outside the subsystem look things over. > >> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > >> believe this is something we can work on in the container runtimes team > >> to implement the container auditing code in CRI-O and Podman. > > Thanks Dan. If I pulled this into a branch and built you some test > > kernels to play with, any idea how long it might take to get a proof > > of concept working on the cri-o side? > We'd need to merge user space patches and let them use that instead of > the > raw interface. I'm not going to merge user space until we are pretty > sure the > patch is going into the kernel. > >>> I have an f29 test rpm of the userspace bits if that helps for testing: > >>> http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > >>> > >>> Here's what it contains (minus the last patch): > >>> > >>> https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > >>> > -Steve > > > FWIW, I've also reached out to some of the LXC folks I know to get > > their take on the API. I think if we can get two different container > > runtimes to give the API a thumbs-up then I think we are in good shape > > with respect to the userspace interface. > > > > I just finished looking over the last of the pending audit kernel > > patches that were queued waiting for the merge window to open so this > > is next on my list to look at. I plan to start doing that > > tonight/tomorrow, and as long as the changes between v5/v6 are not > > that big, it shouldn't take too long. > >>> - RGB > >>> > >>> -- > >>> Richard Guy Briggs > >>> Sr. S/W Engineer, Kernel Security, Base Operating Systems > >>> Remote, Ottawa, Red Hat Canada > >>> IRC: rgb, SunRaycer > >>> Voice: +1.647.777.2635, Internal: (81) 32635 > >> Our current thoughts are to put the setting of the ID inside of conmon, > >> and then launching the OCI Runtime. In a perfect world this would > >> happen in the OCI Runtime, but we have no controls over different OCI > >> Runtimes. > >> > >> By putting it into conmon, then CRI-O and Podman will automatically get > >> the container id support. After we have this we have to plumb it back > >> up through the contianer engines to be able to easily report the link > >> between the Container UUID and The Kernel Container Audit ID. > > I'm glad you guys have a plan, that's encouraging, but sadly I have no > > idea about the level of complexity/difficulty involved in modifying > > the various container bits
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 5/29/19 9:17 AM, Paul Moore wrote: > On Wed, May 29, 2019 at 8:03 AM Daniel Walsh wrote: >> On 5/28/19 8:43 PM, Richard Guy Briggs wrote: >>> On 2019-05-28 19:00, Steve Grubb wrote: On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: >> On 4/22/19 9:49 AM, Paul Moore wrote: >>> On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > Implement kernel audit container identifier. I'm sorry, I've lost track of this, where have we landed on it? Are we good for inclusion? >>> I haven't finished going through this latest revision, but unless >>> Richard made any significant changes outside of the feedback from the >>> v5 patchset I'm guessing we are "close". >>> >>> Based on discussions Richard and I had some time ago, I have always >>> envisioned the plan as being get the kernel patchset, tests, docs >>> ready (which Richard has been doing) and then run the actual >>> implemented API by the userland container folks, e.g. cri-o/lxc/etc., >>> to make sure the actual implementation is sane from their perspective. >>> They've already seen the design, so I'm not expecting any real >>> surprises here, but sometimes opinions change when they have actual >>> code in front of them to play with and review. >>> >>> Beyond that, while the cri-o/lxc/etc. folks are looking it over, >>> whatever additional testing we can do would be a big win. I'm >>> thinking I'll pull it into a separate branch in the audit tree >>> (audit/working-container ?) and include that in my secnext kernels >>> that I build/test on a regular basis; this is also a handy way to keep >>> it based against the current audit/next branch. If any changes are >>> needed Richard can either chose to base those changes on audit/next or >>> the separate audit container ID branch; that's up to him. I've done >>> this with other big changes in other trees, e.g. SELinux, and it has >>> worked well to get some extra testing in and keep the patchset "merge >>> ready" while others outside the subsystem look things over. >> Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and >> believe this is something we can work on in the container runtimes team >> to implement the container auditing code in CRI-O and Podman. > Thanks Dan. If I pulled this into a branch and built you some test > kernels to play with, any idea how long it might take to get a proof > of concept working on the cri-o side? We'd need to merge user space patches and let them use that instead of the raw interface. I'm not going to merge user space until we are pretty sure the patch is going into the kernel. >>> I have an f29 test rpm of the userspace bits if that helps for testing: >>> http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ >>> >>> Here's what it contains (minus the last patch): >>> >>> https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 >>> -Steve > FWIW, I've also reached out to some of the LXC folks I know to get > their take on the API. I think if we can get two different container > runtimes to give the API a thumbs-up then I think we are in good shape > with respect to the userspace interface. > > I just finished looking over the last of the pending audit kernel > patches that were queued waiting for the merge window to open so this > is next on my list to look at. I plan to start doing that > tonight/tomorrow, and as long as the changes between v5/v6 are not > that big, it shouldn't take too long. >>> - RGB >>> >>> -- >>> Richard Guy Briggs >>> Sr. S/W Engineer, Kernel Security, Base Operating Systems >>> Remote, Ottawa, Red Hat Canada >>> IRC: rgb, SunRaycer >>> Voice: +1.647.777.2635, Internal: (81) 32635 >> Our current thoughts are to put the setting of the ID inside of conmon, >> and then launching the OCI Runtime. In a perfect world this would >> happen in the OCI Runtime, but we have no controls over different OCI >> Runtimes. >> >> By putting it into conmon, then CRI-O and Podman will automatically get >> the container id support. After we have this we have to plumb it back >> up through the contianer engines to be able to easily report the link >> between the Container UUID and The Kernel Container Audit ID. > I'm glad you guys have a plan, that's encouraging, but sadly I have no > idea about the level of complexity/difficulty involved in modifying > the various container bits for a proof-of-concept? Are we talking a > week or two? A month? More? > If we had the kernel and the libaudit api, it would involve a small effort in conmon, I would figure a few days for a POC. Getting the hole wiring into CRI-O and Podman
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Wed, May 29, 2019 at 8:03 AM Daniel Walsh wrote: > > On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > > On 2019-05-28 19:00, Steve Grubb wrote: > >> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > >>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: > On 4/22/19 9:49 AM, Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > >> wrote: > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>> Implement kernel audit container identifier. > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > >> good for inclusion? > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > believe this is something we can work on in the container runtimes team > to implement the container auditing code in CRI-O and Podman. > >>> Thanks Dan. If I pulled this into a branch and built you some test > >>> kernels to play with, any idea how long it might take to get a proof > >>> of concept working on the cri-o side? > >> We'd need to merge user space patches and let them use that instead of the > >> raw interface. I'm not going to merge user space until we are pretty sure > >> the > >> patch is going into the kernel. > > I have an f29 test rpm of the userspace bits if that helps for testing: > > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > > > Here's what it contains (minus the last patch): > > > > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > > > >> -Steve > >> > >>> FWIW, I've also reached out to some of the LXC folks I know to get > >>> their take on the API. I think if we can get two different container > >>> runtimes to give the API a thumbs-up then I think we are in good shape > >>> with respect to the userspace interface. > >>> > >>> I just finished looking over the last of the pending audit kernel > >>> patches that were queued waiting for the merge window to open so this > >>> is next on my list to look at. I plan to start doing that > >>> tonight/tomorrow, and as long as the changes between v5/v6 are not > >>> that big, it shouldn't take too long. > > - RGB > > > > -- > > Richard Guy Briggs > > Sr. S/W Engineer, Kernel Security, Base Operating Systems > > Remote, Ottawa, Red Hat Canada > > IRC: rgb, SunRaycer > > Voice: +1.647.777.2635, Internal: (81) 32635 > > Our current thoughts are to put the setting of the ID inside of conmon, > and then launching the OCI Runtime. In a perfect world this would > happen in the OCI Runtime, but we have no controls over different OCI > Runtimes. > > By putting it into conmon, then CRI-O and Podman will automatically get > the container id support. After we have this we have to plumb it back > up through the contianer engines to be able to easily report the link > between the Container UUID and The Kernel Container Audit ID. I'm glad you guys have a plan, that's encouraging, but sadly I have no idea about the level of complexity/difficulty involved in modifying the various container bits for a proof-of-concept? Are we talking a week or two? A month? More? -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Tue, May 28, 2019 at 8:44 PM Richard Guy Briggs wrote: > On 2019-05-28 19:00, Steve Grubb wrote: > > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: ... > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > > > believe this is something we can work on in the container runtimes team > > > > to implement the container auditing code in CRI-O and Podman. > > > > > > Thanks Dan. If I pulled this into a branch and built you some test > > > kernels to play with, any idea how long it might take to get a proof > > > of concept working on the cri-o side? > > > > We'd need to merge user space patches and let them use that instead of the > > raw interface. I'm not going to merge user space until we are pretty sure > > the > > patch is going into the kernel. > > I have an f29 test rpm of the userspace bits if that helps for testing: > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > Here's what it contains (minus the last patch): > > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 Yes, exactly. Just as I plan to start making some test kernels for people to play with (assuming v6 looks okay), I think it would be good if Steve could make a test build of the latest audit userspace with the audit container ID patches. It really shouldn't be that hard, and the benefits should far outweigh any time spent generating the tree/builds. -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 5/28/19 8:43 PM, Richard Guy Briggs wrote: > On 2019-05-28 19:00, Steve Grubb wrote: >> On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: >>> On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: On 4/22/19 9:49 AM, Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman >> wrote: >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: >>> Implement kernel audit container identifier. >> I'm sorry, I've lost track of this, where have we landed on it? Are we >> good for inclusion? > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and believe this is something we can work on in the container runtimes team to implement the container auditing code in CRI-O and Podman. >>> Thanks Dan. If I pulled this into a branch and built you some test >>> kernels to play with, any idea how long it might take to get a proof >>> of concept working on the cri-o side? >> We'd need to merge user space patches and let them use that instead of the >> raw interface. I'm not going to merge user space until we are pretty sure >> the >> patch is going into the kernel. > I have an f29 test rpm of the userspace bits if that helps for testing: > http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ > > Here's what it contains (minus the last patch): > > https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > >> -Steve >> >>> FWIW, I've also reached out to some of the LXC folks I know to get >>> their take on the API. I think if we can get two different container >>> runtimes to give the API a thumbs-up then I think we are in good shape >>> with respect to the userspace interface. >>> >>> I just finished looking over the last of the pending audit kernel >>> patches that were queued waiting for the merge window to open so this >>> is next on my list to look at. I plan to start doing that >>> tonight/tomorrow, and as long as the changes between v5/v6 are not >>> that big, it shouldn't take too long. > - RGB > > -- > Richard Guy Briggs > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 Our current thoughts are to put the setting of the ID inside of conmon, and then launching the OCI Runtime. In a perfect world this would happen in the OCI Runtime, but we have no controls over different OCI Runtimes. By putting it into conmon, then CRI-O and Podman will automatically get the container id support. After we have this we have to plumb it back up through the contianer engines to be able to easily report the link between the Container UUID and The Kernel Container Audit ID.
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 2019-05-28 19:00, Steve Grubb wrote: > On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: > > > On 4/22/19 9:49 AM, Paul Moore wrote: > > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman > wrote: > > > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > >>> Implement kernel audit container identifier. > > > >> > > > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > > > >> good for inclusion? > > > > > > > > I haven't finished going through this latest revision, but unless > > > > Richard made any significant changes outside of the feedback from the > > > > v5 patchset I'm guessing we are "close". > > > > > > > > Based on discussions Richard and I had some time ago, I have always > > > > envisioned the plan as being get the kernel patchset, tests, docs > > > > ready (which Richard has been doing) and then run the actual > > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > > to make sure the actual implementation is sane from their perspective. > > > > They've already seen the design, so I'm not expecting any real > > > > surprises here, but sometimes opinions change when they have actual > > > > code in front of them to play with and review. > > > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > > whatever additional testing we can do would be a big win. I'm > > > > thinking I'll pull it into a separate branch in the audit tree > > > > (audit/working-container ?) and include that in my secnext kernels > > > > that I build/test on a regular basis; this is also a handy way to keep > > > > it based against the current audit/next branch. If any changes are > > > > needed Richard can either chose to base those changes on audit/next or > > > > the separate audit container ID branch; that's up to him. I've done > > > > this with other big changes in other trees, e.g. SELinux, and it has > > > > worked well to get some extra testing in and keep the patchset "merge > > > > ready" while others outside the subsystem look things over. > > > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > > believe this is something we can work on in the container runtimes team > > > to implement the container auditing code in CRI-O and Podman. > > > > Thanks Dan. If I pulled this into a branch and built you some test > > kernels to play with, any idea how long it might take to get a proof > > of concept working on the cri-o side? > > We'd need to merge user space patches and let them use that instead of the > raw interface. I'm not going to merge user space until we are pretty sure the > patch is going into the kernel. I have an f29 test rpm of the userspace bits if that helps for testing: http://people.redhat.com/~rbriggs/ghak90/git-1db7e21/ Here's what it contains (minus the last patch): https://github.com/linux-audit/audit-userspace/compare/master...rgbriggs:ghau40-containerid-filter.v7.0 > -Steve > > > FWIW, I've also reached out to some of the LXC folks I know to get > > their take on the API. I think if we can get two different container > > runtimes to give the API a thumbs-up then I think we are in good shape > > with respect to the userspace interface. > > > > I just finished looking over the last of the pending audit kernel > > patches that were queued waiting for the merge window to open so this > > is next on my list to look at. I plan to start doing that > > tonight/tomorrow, and as long as the changes between v5/v6 are not > > that big, it shouldn't take too long. - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Tuesday, May 28, 2019 6:26:47 PM EDT Paul Moore wrote: > On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: > > On 4/22/19 9:49 AM, Paul Moore wrote: > > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > >>> Implement kernel audit container identifier. > > >> > > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > > >> good for inclusion? > > > > > > I haven't finished going through this latest revision, but unless > > > Richard made any significant changes outside of the feedback from the > > > v5 patchset I'm guessing we are "close". > > > > > > Based on discussions Richard and I had some time ago, I have always > > > envisioned the plan as being get the kernel patchset, tests, docs > > > ready (which Richard has been doing) and then run the actual > > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > > to make sure the actual implementation is sane from their perspective. > > > They've already seen the design, so I'm not expecting any real > > > surprises here, but sometimes opinions change when they have actual > > > code in front of them to play with and review. > > > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > > whatever additional testing we can do would be a big win. I'm > > > thinking I'll pull it into a separate branch in the audit tree > > > (audit/working-container ?) and include that in my secnext kernels > > > that I build/test on a regular basis; this is also a handy way to keep > > > it based against the current audit/next branch. If any changes are > > > needed Richard can either chose to base those changes on audit/next or > > > the separate audit container ID branch; that's up to him. I've done > > > this with other big changes in other trees, e.g. SELinux, and it has > > > worked well to get some extra testing in and keep the patchset "merge > > > ready" while others outside the subsystem look things over. > > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > > believe this is something we can work on in the container runtimes team > > to implement the container auditing code in CRI-O and Podman. > > Thanks Dan. If I pulled this into a branch and built you some test > kernels to play with, any idea how long it might take to get a proof > of concept working on the cri-o side? We'd need to merge user space patches and let them use that instead of the raw interface. I'm not going to merge user space until we are pretty sure the patch is going into the kernel. -Steve > FWIW, I've also reached out to some of the LXC folks I know to get > their take on the API. I think if we can get two different container > runtimes to give the API a thumbs-up then I think we are in good shape > with respect to the userspace interface. > > I just finished looking over the last of the pending audit kernel > patches that were queued waiting for the merge window to open so this > is next on my list to look at. I plan to start doing that > tonight/tomorrow, and as long as the changes between v5/v6 are not > that big, it shouldn't take too long.
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Tue, May 28, 2019 at 5:54 PM Daniel Walsh wrote: > > On 4/22/19 9:49 AM, Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>> Implement kernel audit container identifier. > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > >> good for > >> inclusion? > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > believe this is something we can work on in the container runtimes team > to implement the container auditing code in CRI-O and Podman. Thanks Dan. If I pulled this into a branch and built you some test kernels to play with, any idea how long it might take to get a proof of concept working on the cri-o side? FWIW, I've also reached out to some of the LXC folks I know to get their take on the API. I think if we can get two different container runtimes to give the API a thumbs-up then I think we are in good shape with respect to the userspace interface. I just finished looking over the last of the pending audit kernel patches that were queued waiting for the merge window to open so this is next on my list to look at. I plan to start doing that tonight/tomorrow, and as long as the changes between v5/v6 are not that big, it shouldn't take too long. -- paul moore www.paul-moore.com
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 2019-05-28 17:53, Daniel Walsh wrote: > On 4/22/19 9:49 AM, Paul Moore wrote: > > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > >>> Implement kernel audit container identifier. > >> I'm sorry, I've lost track of this, where have we landed on it? Are we > >> good for > >> inclusion? > > I haven't finished going through this latest revision, but unless > > Richard made any significant changes outside of the feedback from the > > v5 patchset I'm guessing we are "close". > > > > Based on discussions Richard and I had some time ago, I have always > > envisioned the plan as being get the kernel patchset, tests, docs > > ready (which Richard has been doing) and then run the actual > > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > > to make sure the actual implementation is sane from their perspective. > > They've already seen the design, so I'm not expecting any real > > surprises here, but sometimes opinions change when they have actual > > code in front of them to play with and review. > > > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > > whatever additional testing we can do would be a big win. I'm > > thinking I'll pull it into a separate branch in the audit tree > > (audit/working-container ?) and include that in my secnext kernels > > that I build/test on a regular basis; this is also a handy way to keep > > it based against the current audit/next branch. If any changes are > > needed Richard can either chose to base those changes on audit/next or > > the separate audit container ID branch; that's up to him. I've done > > this with other big changes in other trees, e.g. SELinux, and it has > > worked well to get some extra testing in and keep the patchset "merge > > ready" while others outside the subsystem look things over. > > > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and > believe this is something we can work on in the container runtimes team > to implement the container auditing code in CRI-O and Podman. Thanks Dan, Mrunal! - RGB -- Richard Guy Briggs Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada IRC: rgb, SunRaycer Voice: +1.647.777.2635, Internal: (81) 32635
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 4/22/19 9:49 AM, Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: >> On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: >>> Implement kernel audit container identifier. >> I'm sorry, I've lost track of this, where have we landed on it? Are we good >> for >> inclusion? > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. > Mrunal Patel (maintainer of CRI-O) and I have reviewed the API, and believe this is something we can work on in the container runtimes team to implement the container auditing code in CRI-O and Podman.
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Mon, Apr 22, 2019 at 09:49:05AM -0400, Paul Moore wrote: > On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > > Implement kernel audit container identifier. > > > > I'm sorry, I've lost track of this, where have we landed on it? Are we good > > for > > inclusion? > > I haven't finished going through this latest revision, but unless > Richard made any significant changes outside of the feedback from the > v5 patchset I'm guessing we are "close". > > Based on discussions Richard and I had some time ago, I have always > envisioned the plan as being get the kernel patchset, tests, docs > ready (which Richard has been doing) and then run the actual > implemented API by the userland container folks, e.g. cri-o/lxc/etc., > to make sure the actual implementation is sane from their perspective. > They've already seen the design, so I'm not expecting any real > surprises here, but sometimes opinions change when they have actual > code in front of them to play with and review. > > Beyond that, while the cri-o/lxc/etc. folks are looking it over, > whatever additional testing we can do would be a big win. I'm > thinking I'll pull it into a separate branch in the audit tree > (audit/working-container ?) and include that in my secnext kernels > that I build/test on a regular basis; this is also a handy way to keep > it based against the current audit/next branch. If any changes are > needed Richard can either chose to base those changes on audit/next or > the separate audit container ID branch; that's up to him. I've done > this with other big changes in other trees, e.g. SELinux, and it has > worked well to get some extra testing in and keep the patchset "merge > ready" while others outside the subsystem look things over. > That all sounds good, thank you Paul. I knew you and Richard were working on it, but I somehow managed to loose track of exactly where we left this. Much Appreciated Neil > -- > paul moore > www.paul-moore.com > -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Mon, Apr 22, 2019 at 7:38 AM Neil Horman wrote: > On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > > Implement kernel audit container identifier. > > I'm sorry, I've lost track of this, where have we landed on it? Are we good > for > inclusion? I haven't finished going through this latest revision, but unless Richard made any significant changes outside of the feedback from the v5 patchset I'm guessing we are "close". Based on discussions Richard and I had some time ago, I have always envisioned the plan as being get the kernel patchset, tests, docs ready (which Richard has been doing) and then run the actual implemented API by the userland container folks, e.g. cri-o/lxc/etc., to make sure the actual implementation is sane from their perspective. They've already seen the design, so I'm not expecting any real surprises here, but sometimes opinions change when they have actual code in front of them to play with and review. Beyond that, while the cri-o/lxc/etc. folks are looking it over, whatever additional testing we can do would be a big win. I'm thinking I'll pull it into a separate branch in the audit tree (audit/working-container ?) and include that in my secnext kernels that I build/test on a regular basis; this is also a handy way to keep it based against the current audit/next branch. If any changes are needed Richard can either chose to base those changes on audit/next or the separate audit container ID branch; that's up to him. I've done this with other big changes in other trees, e.g. SELinux, and it has worked well to get some extra testing in and keep the patchset "merge ready" while others outside the subsystem look things over. -- paul moore www.paul-moore.com -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On Mon, Apr 08, 2019 at 11:39:07PM -0400, Richard Guy Briggs wrote: > Implement kernel audit container identifier. > > This patchset is a fifth based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > The first patch was the last patch from ghak81 that was absorbed into > this patchset since its primary justification is the rest of this > patchset. > > The second patch implements the proc fs write to set the audit container > identifier of a process, emitting an AUDIT_CONTAINER_OP record to > announce the registration of that audit container identifier on that > process. This patch requires userspace support for record acceptance > and proper type display. > > The third implements reading the audit container identifier from the > proc filesystem for debugging. This patch wasn't planned for upstream > inclusion but is starting to become more likely. > > The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit > container identifier is associated with an event. This patch requires > userspace support for proper type display. > > The 5th adds audit daemon signalling provenance through audit_sig_info2. > > The 6th creates a local audit context to be able to bind a standalone > record with a locally created auxiliary record. > > The 7th patch adds audit container identifier records to the user > standalone records. > > The 8th adds audit container identifier filtering to the exit, > exclude and user lists. This patch adds the AUDIT_CONTID field and > requires auditctl userspace support for the --contid option. > > The 9th adds network namespace audit container identifier labelling > based on member tasks' audit container identifier labels. > > The 10th adds audit container identifier support to standalone netfilter > records that don't have a task context and lists each container to which > that net namespace belongs. > > Example: Set an audit container identifier of 123456 to the "sleep" task: > > sleep 2& > child=$! > echo 123456 > /proc/$child/audit_containerid; echo $? > ausearch -ts recent -m container_op > echo child:$child contid:$( cat /proc/$child/audit_containerid) > > This should produce a record such as: > > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set > opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root > uid=root tty=ttyS0 ses=1 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash > exe=/usr/bin/bash res=yes > > > Example: Set a filter on an audit container identifier 123459 on > /tmp/tmpcontainerid: > > contid=123459 > key=tmpcontainerid > auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); > close(\$tmpfile);" & > child=$! > echo $contid > /proc/$child/audit_containerid > sleep 2 > ausearch -i -ts recent -k $key > auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > rm -f /tmp/$key > > This should produce an event such as: > > type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459 > type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e > sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 > name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE > cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ > inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none > cap_fe=0 cap_fver=0 > type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root > type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 > syscall=openat success=yes exit=3 a0=0xff9c a1=0x5621f2b81900 > a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=ttyS0 ses=1 comm=perl exe=/usr/bin/perl > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=tmpcontainerid > > Example: Test multiple containers on one netns: > > sleep 5 & > child1=$! > containerid1=123451 > echo $containerid1 > /proc/$child1/audit_containerid > sleep 5 & > child2=$! > containerid2=123452 > echo $containerid2 > /proc/$child2/audit_containerid > iptables -I INPUT -i lo -p icmp --icmp-type echo-request -j AUDIT --type > accept > iptables -I INPUT -t mangle -i lo -p icmp --icmp-type echo-request -j MARK > --set-mark 0x1234 > sleep 1; > bash -c "ping -q -c 1 127.0.0.1 >/dev/null 2>&1" > sleep 1; > ausearch -i -m NETFILTER_PKT -ts boot|grep mark=0x1234 > ausearch -i -m NETFILTER_P
Re: [PATCH ghak90 V6 00/10] audit: implement container identifier
On 2019-04-08 23:39, Richard Guy Briggs wrote: > Implement kernel audit container identifier. Here's a first revision of the conversion of my manual test script from bash to automated perl in the audit-testsuite: https://github.com/linux-audit/audit-testsuite/pull/83 It revealed some bugs/limitations in userspace code. One is an omission in my userspace code support for these features that treat the contid field in the CONATAINER_ID auxiliary record to the NETFILTER_PKT record as a comma separated list (I already have a patch). Another is the inability to search on contid in CONTAINER_ID fields (complicated by the previous issue). A third (already noted in ghau86) is the failure to group records of the same event if the record number is in the 1000 block. Another is pondering the addition of an old-contid search option. Despite these limitations, the test script works. > This patchset is a fifth based on the proposal document (V3) > posted: > https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html > > The first patch was the last patch from ghak81 that was absorbed into > this patchset since its primary justification is the rest of this > patchset. > > The second patch implements the proc fs write to set the audit container > identifier of a process, emitting an AUDIT_CONTAINER_OP record to > announce the registration of that audit container identifier on that > process. This patch requires userspace support for record acceptance > and proper type display. > > The third implements reading the audit container identifier from the > proc filesystem for debugging. This patch wasn't planned for upstream > inclusion but is starting to become more likely. > > The fourth implements the auxiliary record AUDIT_CONTAINER_ID if an audit > container identifier is associated with an event. This patch requires > userspace support for proper type display. > > The 5th adds audit daemon signalling provenance through audit_sig_info2. > > The 6th creates a local audit context to be able to bind a standalone > record with a locally created auxiliary record. > > The 7th patch adds audit container identifier records to the user > standalone records. > > The 8th adds audit container identifier filtering to the exit, > exclude and user lists. This patch adds the AUDIT_CONTID field and > requires auditctl userspace support for the --contid option. > > The 9th adds network namespace audit container identifier labelling > based on member tasks' audit container identifier labels. > > The 10th adds audit container identifier support to standalone netfilter > records that don't have a task context and lists each container to which > that net namespace belongs. > > Example: Set an audit container identifier of 123456 to the "sleep" task: > > sleep 2& > child=$! > echo 123456 > /proc/$child/audit_containerid; echo $? > ausearch -ts recent -m container_op > echo child:$child contid:$( cat /proc/$child/audit_containerid) > > This should produce a record such as: > > type=CONTAINER_OP msg=audit(2018-06-06 12:39:29.636:26949) : op=set > opid=2209 contid=123456 old-contid=18446744073709551615 pid=628 auid=root > uid=root tty=ttyS0 ses=1 > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 comm=bash > exe=/usr/bin/bash res=yes > > > Example: Set a filter on an audit container identifier 123459 on > /tmp/tmpcontainerid: > > contid=123459 > key=tmpcontainerid > auditctl -a exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > perl -e "sleep 1; open(my \$tmpfile, '>', \"/tmp/$key\"); > close(\$tmpfile);" & > child=$! > echo $contid > /proc/$child/audit_containerid > sleep 2 > ausearch -i -ts recent -k $key > auditctl -d exit,always -F dir=/tmp -F perm=wa -F contid=$contid -F key=$key > rm -f /tmp/$key > > This should produce an event such as: > > type=CONTAINER_ID msg=audit(2018-06-06 12:46:31.707:26953) : contid=123459 > type=PROCTITLE msg=audit(2018-06-06 12:46:31.707:26953) : proctitle=perl -e > sleep 1; open(my $tmpfile, '>', "/tmp/tmpcontainerid"); close($tmpfile); > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=1 > name=/tmp/tmpcontainerid inode=25656 dev=00:26 mode=file,644 ouid=root > ogid=root rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 nametype=CREATE > cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 > type=PATH msg=audit(2018-06-06 12:46:31.707:26953) : item=0 name=/tmp/ > inode=8985 dev=00:26 mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:tmp_t:s0 nametype=PARENT cap_fp=none cap_fi=none > cap_fe=0 cap_fver=0 > type=CWD msg=audit(2018-06-06 12:46:31.707:26953) : cwd=/root > type=SYSCALL msg=audit(2018-06-06 12:46:31.707:26953) : arch=x86_64 > syscall=openat success=yes exit=3 a0=0xff9c a1=0x5621f2b81900 > a2=O_WRONLY|O_CREAT|O_TRUNC a3=0x1b6 items=2 ppid=628 pid=2232 auid=root > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=r
