News for hackers. Stuff that matters.
Re:Containers as Kernel Objects – Again by gigatexal on Sunday February 24, 2019 @04:12AM (#19237839)
Seems like a great way to get rootkits into the Linux kernel ...
Re:Containers as Kernel Objects – Again by TheRealPomax on Sunday February 24, 2019 @01:17PM (#19239745)
why would it be any more prone to getting rootkits in the kernel than any other process that was granted kernel access to do "this thing you think you need to do"?
Re:Containers as Kernel Objects – Again by dastx on Sunday February 24, 2019 @08:51AM (#19238547)
How so?
Re:Containers as Kernel Objects – Again by k__ on Sunday February 24, 2019 @09:01AM (#19238573)
On trusting trust
Re:Containers as Kernel Objects – Again by gigatexal on Sunday February 24, 2019 @10:18AM (#19238849)
How would you be able to root out these containers doing seemingly anything sitting in kernelspace?
Re:Containers as Kernel Objects – Again by cpuguy83 on Sunday February 24, 2019 @10:28AM (#19238889)
The code wouldn't be running in kernel space, just the setup/configuration of the environment, which really isn't any different than it is today, tbh. This seems to be more about attaching a kernel auditable id to a container.
Re:Containers as Kernel Objects – Again by metabagel on Sunday February 24, 2019 @12:42PM (#19239564)
It sounds like what you are talking about is already existing functionality, not the proposed design.
Re:Containers as Kernel Objects – Again by simcop2387 on Sunday February 24, 2019 @02:13PM (#19240055)
The proposed design uses all the existing functionality and gives it a single object in the kernel to control it rather than a dozen different ones. It's not a fundamental change in design to how the containers themselves work.
Re:Containers as Kernel Objects – Again by gigatexal on Sunday February 24, 2019 @05:29PM (#19241042)
Ahh, well I stand corrected.