Building a SECURE cointainer using Cgroups ?

Building a SECURE cointainer using Cgroups ?

[Tanaka, Thomas]

Hello,



Is it possible to build a secure container by using cgroups? My goal is to achieve a file system namespace container that will limit the file system view given to a process similar to chroot does but of course has to be secure.



Thank you in advance for your attentions and help.



Regards,



Thomas

Re: Building a SECURE cointainer using Cgroups ?

[Dave Hansen]

On Mon, 2008-10-13 at 10:03 -0700, Tanaka, Thomas wrote:
> Is it possible to build a secure container by using cgroups? My goal
> is to achieve a file system namespace container that will limit the
> file system view given to a process similar to chroot does but of
> course has to be secure.

You'll have to be a bit more specific than that.  Do you want to make
absolutely sure that certain containers have absolutely no access to
certain fs namespaces?

-- Dave

RE: Building a SECURE cointainer using Cgroups ?

[Tanaka, Thomas]

Yes absolutely that is what I am trying to achieve.

> Is it possible to build a secure container by using cgroups? My goal
> is to achieve a file system namespace container that will limit the
> file system view given to a process similar to chroot does but of
> course has to be secure.

You'll have to be a bit more specific than that.  Do you want to make
absolutely sure that certain containers have absolutely no access to
certain fs namespaces?

-- Dave

RE: Building a SECURE cointainer using Cgroups ?

[Dave Hansen]

On Mon, 2008-10-13 at 11:01 -0700, Tanaka, Thomas wrote:
> Yes absolutely that is what I am trying to achieve.

I'm going to put on my Serge hat and bet that you can do it with
security modules. :)

There's nothing that cgroups or containers gives you that will help with
your problem.  We actually haven't touched the fs namespaces at all, yet
because they work great as they stand today.

-- Dave

Re: Building a SECURE cointainer using Cgroups ?

[Serge E. Hallyn]

Quoting Dave Hansen (dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On Mon, 2008-10-13 at 11:01 -0700, Tanaka, Thomas wrote:
> > Yes absolutely that is what I am trying to achieve.
> 
> I'm going to put on my Serge hat and bet that you can do it with
> security modules. :)

Right, your goal is still not very precise, but a security module -
smack or selinux - might be your best bet.

> There's nothing that cgroups or containers gives you that will help with
> your problem.  We actually haven't touched the fs namespaces at all, yet
> because they work great as they stand today.

No, but there is the device whitelist cgroup and capability bounding
sets - perhaps that is what he is asking about?

If you have a normal chroot - or a container created with
clone(CLONE_NEWNS) followed by pivot_root into a completely isolated
file system tree (say, created using debootstrap), then a root user in
that pivot_root can simply mount /dev/hda1 /mnt and chroot back into
that.

So to make the above a little more secure, you can

	1. restrict the container's device whitelist so that it can't
	   create or use the devices representing the hard drive.
or
	2. take CAP_MKNOD and CAP_SYS_ADMIN out of the containers'
	   capability bounding set and pI, so that root can neither
	   mount any filesystems nor create any devices.  (Of course,
	   also make sure /dev is suitably empty)  The problem with
	   this one is that we still don't have a check upstream to
	   force mounts by a user who does not have CAP_MKNOD to be
	   nodev.  That's one reason I keep trying to push on the
	   user mounts patchset - it brings that check.

-serge

RE: Building a SECURE cointainer using Cgroups ?

[Tanaka, Thomas]

Thanks for the quick reply.
Just out of curiosity, Is it possible to develop a cgroup subsystem that just does the filesystem isolation?

Quoting Dave Hansen (dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> On Mon, 2008-10-13 at 11:01 -0700, Tanaka, Thomas wrote:
> > Yes absolutely that is what I am trying to achieve.
>
> I'm going to put on my Serge hat and bet that you can do it with
> security modules. :)

Right, your goal is still not very precise, but a security module -
smack or selinux - might be your best bet.

> There's nothing that cgroups or containers gives you that will help with
> your problem.  We actually haven't touched the fs namespaces at all, yet
> because they work great as they stand today.

No, but there is the device whitelist cgroup and capability bounding
sets - perhaps that is what he is asking about?

If you have a normal chroot - or a container created with
clone(CLONE_NEWNS) followed by pivot_root into a completely isolated
file system tree (say, created using debootstrap), then a root user in
that pivot_root can simply mount /dev/hda1 /mnt and chroot back into
that.

So to make the above a little more secure, you can

        1. restrict the container's device whitelist so that it can't
           create or use the devices representing the hard drive.
or
        2. take CAP_MKNOD and CAP_SYS_ADMIN out of the containers'
           capability bounding set and pI, so that root can neither
           mount any filesystems nor create any devices.  (Of course,
           also make sure /dev is suitably empty)  The problem with
           this one is that we still don't have a check upstream to
           force mounts by a user who does not have CAP_MKNOD to be
           nodev.  That's one reason I keep trying to push on the
           user mounts patchset - it brings that check.

-serge

Re: Building a SECURE cointainer using Cgroups ?

[Serge E. Hallyn]

Quoting Tanaka, Thomas (thomas.tanaka-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org):
> Thanks for the quick reply.
> Just out of curiosity, Is it possible to develop a cgroup subsystem that just does the filesystem isolation?

Exactly what filesystem isolation?

-serge

RE: Building a SECURE cointainer using Cgroups ?

[Tanaka, Thomas]

I should have said filesystem namespace isolation. For example, isolating a process from accessing proc, sys, such that it is only able to access a predefined list of directory.

Quoting Tanaka, Thomas (thomas.tanaka-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org):
> Thanks for the quick reply.
> Just out of curiosity, Is it possible to develop a cgroup subsystem that just does the filesystem isolation?

Exactly what filesystem isolation?

-serge

Re: Building a SECURE cointainer using Cgroups ?

[Daniel P. Berrange]

On Mon, Oct 13, 2008 at 02:29:21PM -0500, Serge E. Hallyn wrote:
> Quoting Dave Hansen (dave-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org):
> > On Mon, 2008-10-13 at 11:01 -0700, Tanaka, Thomas wrote:
> > > Yes absolutely that is what I am trying to achieve.
> > 
> > I'm going to put on my Serge hat and bet that you can do it with
> > security modules. :)
> 
> Right, your goal is still not very precise, but a security module -
> smack or selinux - might be your best bet.
> 
> > There's nothing that cgroups or containers gives you that will help with
> > your problem.  We actually haven't touched the fs namespaces at all, yet
> > because they work great as they stand today.
> 
> No, but there is the device whitelist cgroup and capability bounding
> sets - perhaps that is what he is asking about?
> 
> If you have a normal chroot - or a container created with
> clone(CLONE_NEWNS) followed by pivot_root into a completely isolated
> file system tree (say, created using debootstrap), then a root user in
> that pivot_root can simply mount /dev/hda1 /mnt and chroot back into
> that.
> 
> So to make the above a little more secure, you can
> 
> 	1. restrict the container's device whitelist so that it can't
> 	   create or use the devices representing the hard drive.

We follow this appraoch & use the device whitelist capability in libvirt's
LXC driver now for exactly this purpose. Works quite nicely really. There
are still some other holes like a private dev-pts but those are in progress

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|