*** zerocoolback has joined #kata-dev | 00:33 | |
*** zerocoolback has quit IRC | 00:51 | |
*** zerocoolback has joined #kata-dev | 02:28 | |
*** minmin has joined #kata-dev | 03:02 | |
*** minmin has quit IRC | 03:06 | |
*** minmin has joined #kata-dev | 03:10 | |
*** zerocoolback has quit IRC | 03:27 | |
*** minmin has quit IRC | 04:16 | |
*** zerocoolback has joined #kata-dev | 04:20 | |
kata-irc-bot | <fupan> @cole.mickens I had fixed the hooks issue, you can have a try with ctr now. | 04:30 |
---|---|---|
*** marcov has joined #kata-dev | 05:59 | |
*** zerocoolback has quit IRC | 06:38 | |
*** zerocool_ has joined #kata-dev | 06:41 | |
*** zerocool_ has quit IRC | 06:47 | |
*** zerocoolback has joined #kata-dev | 06:48 | |
*** zerocoolback has quit IRC | 06:53 | |
*** marcov has quit IRC | 06:53 | |
*** marcov has joined #kata-dev | 06:53 | |
*** jodh has joined #kata-dev | 06:55 | |
*** zerocoolback has joined #kata-dev | 07:55 | |
*** davidgiluk has joined #kata-dev | 07:56 | |
*** gwhaley has joined #kata-dev | 08:06 | |
*** zerocoolback has quit IRC | 08:12 | |
*** zerocoolback has joined #kata-dev | 08:15 | |
*** zerocoolback has quit IRC | 08:46 | |
*** zerocoolback has joined #kata-dev | 09:31 | |
*** zerocoolback has quit IRC | 09:32 | |
*** zerocoolback has joined #kata-dev | 09:32 | |
*** zerocoolback has quit IRC | 09:47 | |
*** davidgiluk has quit IRC | 10:12 | |
*** davidgiluk has joined #kata-dev | 10:39 | |
*** gwhaley has quit IRC | 10:59 | |
*** jugs has quit IRC | 11:13 | |
*** jugs has joined #kata-dev | 11:15 | |
*** zerocoolback has joined #kata-dev | 11:54 | |
*** zerocoolback has quit IRC | 12:15 | |
*** zerocoolback has joined #kata-dev | 12:15 | |
*** gwhaley has joined #kata-dev | 12:25 | |
*** davidgiluk has quit IRC | 12:40 | |
*** davidgiluk has joined #kata-dev | 12:41 | |
*** devimc has joined #kata-dev | 12:50 | |
*** eernst has joined #kata-dev | 14:17 | |
*** eernst has quit IRC | 14:19 | |
*** eernst has joined #kata-dev | 14:19 | |
*** eernst has quit IRC | 14:23 | |
*** eernst_ has joined #kata-dev | 14:23 | |
gwhaley | kata arch call in 10 minutes? | 14:50 |
kata-irc-bot | <raravena80> yeppers | 14:57 |
kata-irc-bot | <xu> why at jessie :,) | 14:59 |
kata-irc-bot | <yonatan.gefen> Hey everyone, hope you had a nice weekend! GE is interested in adopting Kata for embedded applications (healthcare, aviation, power generation, etc. ) and in contributing to the Kata project. We want to start by creating a demo to excite others at GE about Kata during a symposium next week (September 25th) , so there is some urgency. Currently, we have incorporated Kata Containers into our Yocto-Project based embedded Linux | 15:00 |
kata-irc-bot | distribution and have performed some basic tests to ensure proper operation. We would like to present a convincing demonstration that Kata Containers provide a meaningful enhancement over our current Docker container approach to application deployment. We believe that enhanced security will form a strong argument for the adoption of Kata, however, we are open to ideas for demos of additional features/improvements over Docker besides security. We | 15:00 |
kata-irc-bot | have seen a Kata video of a mitigation of CVE-2017-5123 and heard there is also one of CVE-2016-5195 (Dirty Cow) as well, but are there any demos of more recent exploits or security flaws we can use? Unless I am mistaken, CVE-2017-5123 only affect kernel versions 4.12-4.13, so one can build their Docker Image using an older or newer kernel rev. Also, I understand that other patches have been applied to correct CVE-2016-5195. Any help would be | 15:00 |
kata-irc-bot | greatly appreciated. Thank you in advance! | 15:00 |
kata-irc-bot | <xu> yes, 5123 is fixed after 4.13 | 15:01 |
gwhaley | xu - ha ha - poor old jessie :-) | 15:01 |
gwhaley | I thought we were going to s/j e s s i e/eric/ now :-) | 15:02 |
kata-irc-bot | <xu> you know, almost every published CVE is fixed | 15:02 |
kata-irc-bot | <raravena80> The funky irc implementation :,) | 15:02 |
kata-irc-bot | <yonatan.gefen> @xu, thanks for the response! :slightly_smiling_face: If the CVE's are almost all fixed (or are fixed shortly after they are published?), what then can we use to demostrate the advantage of using Kata Containers over regular Docker Containers? | 15:05 |
kata-irc-bot | <xu> We chose an affected kernel for the demo, both host and kata guest kernel. The explanation is, even with an unknown exploit, the extra isolation layer helps kata to protect the system. | 15:07 |
kata-irc-bot | <yonatan.gefen> I see. So you used a known vulnerability (for which a fix already exists) for demo purposes only. The argument is that Kata would protect you from a future and yet unknown vulnerability . Do you happen to have a similar demo for a more recent CVE? | 15:12 |
*** zerocoolback has quit IRC | 15:15 | |
kata-irc-bot | <xu> Unfortunately no, there are many CVEs, however, only a small set of them are suit for a demo, we select the 5123 and demo it this June, and did not do further investigation on the CVEs | 15:27 |
kata-irc-bot | <anne> I heard a stat recently that in each kernel release there's an average of 3 privilege escalation vulnerabilities? (I haven't verified this stat) But that makes the "yet unknown" a little bit closer to home | 15:28 |
kata-irc-bot | <yonatan.gefen> Ok thank you very much @xu, and thank you @anne for the stat! | 15:32 |
kata-irc-bot | <xu> you are welcome | 15:32 |
*** dklyle has quit IRC | 15:49 | |
*** dklyle has joined #kata-dev | 15:50 | |
kata-irc-bot | <sebastien.boeuf> @fupan around? | 15:52 |
kata-irc-bot | <fupan> yes | 15:58 |
kata-irc-bot | <sebastien.boeuf> @fupan I was wondering about agent PR 371 | 16:09 |
kata-irc-bot | <sebastien.boeuf> if the container process terminates, the PID namespace will not exist anymore, and the kernel will kill every process in this namespace, right? | 16:10 |
kata-irc-bot | <sebastien.boeuf> so there's no problem with the potential IO in this case, right? | 16:10 |
kata-irc-bot | <fupan> The container process, you mean the container init process? | 16:14 |
kata-irc-bot | <sebastien.boeuf> yes | 16:14 |
kata-irc-bot | <fupan> yes, for the init process, this case is right | 16:14 |
kata-irc-bot | <sebastien.boeuf> but you're covering the `exec` case? | 16:15 |
kata-irc-bot | <fupan> yes, you are right | 16:16 |
kata-irc-bot | <fupan> For the exec case, the exec process exit doesn’t mean its children process will exit too | 16:17 |
kata-irc-bot | <fupan> which will be adopted by container init process | 16:17 |
kata-irc-bot | <sebastien.boeuf> and the terminal will still be opened, because the child will still be running, right? | 16:21 |
kata-irc-bot | <fupan> yes | 16:21 |
kata-irc-bot | <sebastien.boeuf> any chance we could prevent the process from sharing its terminal wiht its children? | 16:21 |
kata-irc-bot | <fupan> I don’t think so, this is the linux’s process rule | 16:24 |
kata-irc-bot | <sebastien.boeuf> yeah, I get it, but I was trying to understand if there was no way to handle this without introducing extra code | 16:25 |
kata-irc-bot | <sebastien.boeuf> I'll dig more on that, and I'll ack your PR if I cannot think of any better way | 16:25 |
kata-irc-bot | <fupan> ok, thanks | 16:26 |
*** jodh has quit IRC | 17:06 | |
*** marco_ has joined #kata-dev | 17:13 | |
*** marcov has quit IRC | 17:16 | |
*** marcov__ has joined #kata-dev | 17:25 | |
*** marco_ has quit IRC | 17:27 | |
*** eernst_ has quit IRC | 17:35 | |
*** david-lyle has joined #kata-dev | 17:54 | |
*** gwhaley has quit IRC | 17:57 | |
*** dklyle has quit IRC | 17:57 | |
*** marco_ has joined #kata-dev | 17:59 | |
*** eernst has joined #kata-dev | 18:00 | |
*** eernst has quit IRC | 18:00 | |
*** eernst has joined #kata-dev | 18:01 | |
*** marcov__ has quit IRC | 18:02 | |
*** eernst has quit IRC | 18:04 | |
*** fiddletwix has quit IRC | 18:05 | |
*** marcov__ has joined #kata-dev | 18:15 | |
*** fiddletwix has joined #kata-dev | 18:16 | |
*** marco_ has quit IRC | 18:17 | |
*** fiddletwix has quit IRC | 18:22 | |
*** marco_ has joined #kata-dev | 18:30 | |
*** marcov__ has quit IRC | 18:33 | |
*** eernst has joined #kata-dev | 18:35 | |
*** marco_ has quit IRC | 18:37 | |
*** eernst has quit IRC | 18:37 | |
*** marco_ has joined #kata-dev | 18:38 | |
kata-irc-bot | <margaret.labrecque> @yonatan.gefen maybe we don't have to limit our demo options for the GE event to exploits? | 19:01 |
kata-irc-bot | <margaret.labrecque> Are there GE vertical segments (financial, healthcare, etc.) that would benefit for using (for example) a custom OS inside the Kata VM with Yocto as the host OS? | 19:02 |
davidgiluk | but then what makes that kata as opposed to just a VM? | 19:06 |
kata-irc-bot | <margaret.labrecque> (I may not be answer your Q ... but the Kata VM is much lighterweight and also of course also enables a container-like deployment model - so indeed it can be a baby step for people transitioning from a VM deployment model to that of containers ... in advance of re-writing/container-izing their apps) | 19:13 |
*** davidgiluk has quit IRC | 19:15 | |
kata-irc-bot | <eric.ernst> Hey @davidgiluk - really it'd be a custom kernel in this case. | 19:48 |
kata-irc-bot | <eric.ernst> in case your container workload has specific kernel requirements. | 19:48 |
kata-irc-bot | <eric.ernst> the key (aside from performance) to differentiate from "just a VM" is the agent running in the VM and creating a vsock server to listen (gRPC protocol over this). | 19:49 |
*** eernst has joined #kata-dev | 20:28 | |
*** marco_ has quit IRC | 21:22 | |
*** devimc has quit IRC | 21:40 | |
*** eernst has quit IRC | 21:43 | |
*** eernst has joined #kata-dev | 21:44 | |
*** eernst has quit IRC | 21:46 | |
*** eernst_ has joined #kata-dev | 21:46 | |
*** eernst_ has quit IRC | 21:50 | |
*** annabelleB has joined #kata-dev | 22:10 | |
*** lamego has joined #kata-dev | 23:03 | |
*** lamego is now known as lamego_afk | 23:03 | |
*** lamego_afk has left #kata-dev | 23:03 | |
*** annabelleB has quit IRC | 23:25 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!