Re: [RFC PATCH 3/4] Implement driver for supporting multiple emulated TPMs

["Stefan Berger" <stefanb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4495 bytes --]

Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote on 01/27/2016 
12:58:39 PM:

> 
> On Wed, Jan 27, 2016 at 07:42:17AM -0500, Stefan Berger wrote:
> >    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.
> 
> Presumably who ever is implementing IMA namespaces has some kind of
> solution for this though?
> 
> That seems like a very difficult problem.
> 
> >    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.
> 
> That isn't nearly good enough, mount namespaces don't mean you are
> isolated. It isn't until another tool like docker goes through and
> alters the child's mount table that some degree of isolation is
> achieved..
> 
> 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 the list 
of measurements once the set of namespaces goes away because whatever ran 
there couldn't have influenced the host. I would say mount, network, and 
user namespace is such a set. Probably also include PID namespace in that 
space assuming that in a shared PID namespace one process could signal 
other processes. Though this may be mitigated with user namespace mapping 
etc.. Not clear about UTS namespace, but may not be so important.

To be on the safe side, maybe all would be required and one gets an IMA 
namespace only then.

> 
> 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.

tmpfs /dev tmpfs rw,context=
"system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,mode=755 0 0
devpts /dev/pts devpts rw,context=
"system_u:object_r:svirt_sandbox_file_t:s0:c322,c860
",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
shm /dev/shm tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,nodev,noexec,relatime,size=65536k 
0 0
tmpfs /sys/fs/cgroup tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,nodev,noexec,relatime 
0 0
tmpfs /run/secrets tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,nodev,noexec,relatime 
0 0
tmpfs /proc/kcore tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,mode=755 
0 0
tmpfs /proc/latency_stats tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,mode=755 
0 0
tmpfs /proc/timer_stats tmpfs 
rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c322,c860",nosuid,mode=755 
0 0


> 
> >    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.
> 
> I agree IMA namespaces probably don't need the whole 'ip setns' type
> interface, but realistically if an ioctl is provided to install a TPM
> in a child namespace it should let anyone with privilege in the parent
> namespaces install a TPM in a child IMA namespace, that is just how
> the namespace APIs seem to work.

Agree.

> 
> That said, maybe looking at selinux namespaces interaction will give a
> different idea..

See above. We cannot use the same trick.

   Stefan

> 
> Jason
> 



[-- Attachment #1.2: Type: text/html, Size: 5738 bytes --]

[-- Attachment #2: Type: text/plain, Size: 413 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 192 bytes --]

_______________________________________________
tpmdd-devel mailing list
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel