| *** serverascode has quit IRC | 11:08 | |
| kata-irc-bot | <william> Hi again! The documentations state that capabilities restrictions and seccomp profiles is supported inside the guest. Is it possible to apply similar restrictions between the hypervisor and the host? (I believe this is how gVisor does it, anything the Sentry(emulated Linux Kernel) doesn't call is restricted between the host and the sentry. | 12:28 |
|---|---|---|
| kata-irc-bot | <eric.ernst> Hey @william. For seccomp, for sure. The hard part atm is that Kata runtime requires quite a lot of syscalls, so a proper whitelist would be too large to have a lot of benefit. I have been discussing with others being able to rewrite some of the runtime components in order to make it easier to restrict portions. | 20:46 |
| kata-irc-bot | <eric.ernst> From a threat model perspective, the runtime component on the host is a bit further away from the untrusted part (that is, the actual workload is created inside cgroups/namespaces via the guest linux kernel, which in turn is isolated by hardware virtualization + paravirt devices in, which then is interfaced to via the runtime) | 20:48 |
| kata-irc-bot | <eric.ernst> So... it hasn't been top priority yet, but I think it is work exploring. It could even help with footprint of the runtime component as well, I bet. | 20:48 |
| kata-irc-bot | <william> Alright thanks for clearing that up! gVisor has some pretty heavy seccomp restrictions both on the entire runtime but also varying permissions for different components inside the runtime so I was mostly curious if Kata could benefit from something similar. Security by principle of least privilege... | 23:11 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!