Jarkko Sakkinen <[email protected]> wrote on 01/26/2016
10:13:20 PM:
>
> On Thu, Jan 21, 2016 at 03:10:40PM -0700, Jason Gunthorpe wrote:
> > On Thu, Jan 21, 2016 at 04:51:06PM -0500, Stefan Berger wrote:
> >
> > > > You can't let this influence the kernel UAPI design.
> >
> > > The choice is between getting this working 'today' (even if just
> > > locally) or discussing this with golang designers, which in the
ideal
> > > case would cause me waiting for the next version, dealing with
that
> > > version dependency etc., plus the delay. So, clearly, an
additional
> > > ioctl() and ~50 lines of code make this work 'now'. Doesn't this
seem
> > > worth it?
> >
> > Sorry, for mainline stuff like this reserve thing is not clean enough
> > to be acceptable.
> >
> > Why can't you just open-code a modified forkAndExecInChild in docker?
> >
> > Seriously, the golang code you showed already has special stuff to do
> > user namespaces before the exec, it is totally unreasonable insist
>
> I'm starting to be along the same lines with the Jason now that I've
> actually tried to read through the discussion up to this email. I did
> say something opposite in last week but will take my words back since I
> had too weak understanding back then (you *never* should response to
> dicussions like this when you are overloaded with something else).
>
> I haven't yet locked whether the fd or major/minor passing is the right
> choice but at least I do agree that we cannot make decission based on
> some golang code in Docker. For the new mainline code we should pick the
> most robust API, nothing more or less...
So we can design it how it should work from user space. So far it's solved
with an ioctl.
To pick up on Jason's suggestion to look into network namespaces and
associated tools:
What we don't want from the IMA perspective is that someone creates an IMA
namespace on the host similar to how one can create a network namespace
(ip netns add ...), runs (malicious) programs under a different IMA
policy, and then closes that IMA namespace. On the other hand, what we
want are containers having their own IMA namespace with an independent
policy. Since the argument is that containers are well isolated from the
host and programs running there don't influence the host, their logs would
be independent. The thing is that containers are made up of multiple
namespaces. So, we likely won't give direct control over IMA namespace
creation through tools like network namespacing does or even a dedicate
clone flag but connect it to one or multiple existing clone flags that
cause creation of a (mount, pid, etc.) namespace. So that could mean that
if someone creates a mount + pid namespace, and thus is well isolated, he
automatically gets an IMA namespace.
IMA namespacing would then provide less control for users compared to
network namespacing and therefore an ioctl, issued from the clone()ing
process, for IMA+vTPM driver hook-up would be sufficient.
Stefan
>
> /Jarkko
>
------------------------------------------------------------------------------
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
