On Wed, Jan 27, 2016 at 04:58:51PM -0500, Stefan Berger wrote: > > I don't think there is a generic kernel side point where it could tell > > the child is isolated enough. Whatever that means.
> I agree. Which set of namespaces is enough for running any program in > this set of namespaces (aka container) and being able to forget > about It isn't just the presense of namespaces that matter, eg a net mount namespace does not mean access is denied to the parent namespace, net namespaces don't mean devices are isolated, etc. This is not a good direction to go, access to an IMA namespace needs to be very strongly controlled, 'enough namespaces' is not a sufficient criteria! Any flaw in the access criteria immediately destroys the security of IMA in non-container contexts, so this needs to be done very carefully. > > Doesn't selinux have the exact same problem? How does selinux handle > > namespaces? > They solve it by mounting with a context option, which enforces an > sVirt SELinux label across all files that the container user then > cannot change. This sounds very sane. > > That said, maybe looking at selinux namespaces interaction will give a > > different idea.. > See above. We cannot use the same trick. Hmm, well, it certainly seems to be a lot of what is required, and like a much better direction than trying to use namespaces. Arranging for an IMA namespace to only exists in association with a SELinux label - and then rely on SELinux to provide the necessary security isolation instead of trying to do the same thing with namespaces sounds more likely to succeed.. 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
