On Thu, Jan 21, 2016 at 02:02:17PM -0500, Stefan Berger wrote: > What is IMA namespace in relation to a device's name? The method is to > read the major/minor numbers on the host and created /dev/tpm0 with the > same major/minor numbers in the container's filesystem. The name > doesn't matter I guess, but major/minor are important.
Ostensibly we number the /dev/tpmX's in relation to the tpm index number. Internally to the kernel the TPM access is done by that tpm index. Today, IMA hard codes that index value to 0 (IIRC). I could see a future IMA allowing user space to specify the index. The index is also how to associate the /dev/tpm node with the /sysfs files. So the index is important, we'd want to control it for namespaces. In any case the tpm index is part of the contract, and it would be ideal if the IMA namespace made tpm index 0 be the right vtpm. > The problem I have run into in particular with Docker and golang is > that Docker invokes the golang function to run an external program. The > golang function does a clone(), a whole lot of other stuff after it, > and in the end the execve(). Well, ultimately that is a docker problem, as you describe IMA has a special new requirement where the IMA NS has to be setup quickly. > The code is here: > [1]https://golang.org/src/syscall/exec_linux.go > Look at the function forkAndExecInChildon line 56++. Well, that is just bad API design, sorry. The unix model of fork()/exec() is that the app gets a chance to adjust the environment between fork/exec, and this design, while easy to use, locks the app into the hard wired customization that forkAndExecInChild does. Maybe add a callback to SysProcAttr or something? Can't help you here. You can't let this influence the kernel UAPI design. > available. So, the conclusion is, to accomodate golang (for example) we > can create the device pair, sit the vTPM on top of the master, and > reserve the device pair befor the next clone() so that IMA finds it and > can hook up to it. > What is wrong with this scheme? The ioctl for 'reservation' before the > clone()? Yes, how does that sort of thing even make sense in a complex multi-threaded world? > Should it work like this? Sort of like this: controlfd = open("/dev/vtpmx", ...); ioctl(controlfd, CREATE_VTPM, &inargs, &outargs); serverfd = outargs.fd; // /dev/tpmX exists. X is returned in outargs.tpm_index, maybe return major/minor too child = clone(...) ioctl(??? , ASSIGN_VTPM_TO_NS, .. child->ima_ns .., to index = 0, from index = outargs.tpm_index); /* tpm index X is destroyed, kernel prevents reuse of index X until the NS is destroyed too. /dev/tpmX is removed by udev */ close(severfd); So, you'd probably make a vtpm daemon that took as execv args a reference to the IMA namespace to create the tpm in, and have docker launch it after the clone, but before the exec in the parent namespace. That is fairly similar to how net ns works, with the wrinkle you have to do this before the exec, I guess. It also allows hw tpms to be routed to the ns. The docker container just has the normal /dev/tpm0 Jason ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ tpmdd-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
