brainstorming for UDS-N - Cloud Infrastructure

[Daniel Lezcano]

On 09/29/2010 04:55 PM, Stéphane Graber wrote:
> On Wed, 2010-09-29 at 09:25 -0500, Jamie Strandboge wrote:
>    
>> On Tue, 2010-09-28 at 20:05 -0400, Stéphane Graber wrote:
>>      
>>> On Tue, 2010-09-28 at 21:59 +0200, Allison Randal wrote:
>>>        
>>>> Server topics are included in all the other tracks, but the UDS team
>>>> called out cloud technology for special attention. It's an area where
>>>> Ubuntu is one of the leading players in driving innovation, which means
>>>> it's a big opportunity for us as a community to make a difference in the
>>>> world at large. This includes being a good guest and being a good host,
>>>> as well as evaluating new technologies.
>>>>
>>>> What's high on your list for this area?
>>>> Allison
>>>>          
>>> I guess an important topic when thinking of server is virtualization and
>>> contextualization both for flexibility and security.
>>>
>>> I believe we can greatly improve our VM server solution (my biggest wish
>>> at the moment is for some kind of ACLs on VMs running in libvirt) and
>>> prepare to have a rocking solution for the next LTS.
>>>
>>>        
>> When using qemu/kvm, libvirt can use the AppArmor security driver to
>> confine VMs to only the files they need. This provides guest isolation
>> and userspace host protection. This is on by default in Ubuntu's libvirt
>> since Karmic and is also upstream.
>>      
> I agree that libvirt itself can't do any scary changes on the system
> when using apparmor. What I was more thinking about is the case where
> you have a shared virtualization server with multiple users running VMs.
>
> Something that's seen in other VM infrastructure is that ability to let
> users create VM and manage them while still preventing them from
> accessing/altering anyone else's VM running on that same host.
>
>    
>>      
>>> Contextualization is also something I use everyday as the current policy
>>> at my employer is to have a full container per service. That means that
>>> I currently administer a few hundreds VZ containers just for our
>>> internal infrastructure (a few thousands if including customers).
>>>
>>> Containers offer a lot of flexibility at a very low cost and can be used
>>> to greatly improve everyone's security even on the desktop.
>>> That's really something I believe we should focus more on and I know
>>> there's an existing interest from both the Server and Security team.
>>> We also have the chance to have Daniel Lezcano (upstream for LXC) at UDS
>>> this time.
>>>        
>> AIUI, containers as currently implemented in the vanilla kernel should
>> not be considered secure at this point (at least for root). There are
>> apparently rather large patchsets that the different container upstreams
>> use to address these issues. I'm not up on all the details though, but
>> they can surely be googled.
>>      
> Yes, currently my biggest issue with LXC (as it's in the upstream
> kernel) is the lack of filtering of /proc.
> Anyone can basically access /proc/sysrq-trigger or anything in /sys
> giving hardware access in some cases.
>
> OpenVZ doesn't have that issue as both /proc and /sys are filtered so
> only the bare minimal is available blocking a container root user from
> being able to do anything on the host.
>
> That's mostly why we are still staying on 8.04 here as it's the only
> Ubuntu release with an update OpenVZ kernel. We'll consider switching to
> LXC once these missing "features" are implemented.
>
> Anyway, the current kernel container implementation is still a lot
> better than using any regular chroot and I'm pretty sure that LXC
> upstream is willing to address these remaining issues to see containers
> being used more and more both on the server and the desktop.
>    

I created a blueprint 
https://blueprints.launchpad.net/lxc/+spec/server-natty-lxc-production-ready 
to create a discussion at UDS-N about the linux containers and how to 
make it ready for production.

I am building a list of missing features and the /proc virtualization is 
one of them.

There is a prototype at http://www.tinola.com/lxc/ where we tried to 
virtualize /proc using fuse.
This prototype does three actions on a procfs file / directory :
  (1) proxy the file : the file can be accessed without alteration
  (2) hide the file: the file is not accessible within the container
  (3) shadow the file : show another content of the proc file (useful 
for meminfo, cpuinfo, etc ...)

IMO, it will be very hard to convince the kernel community to change 
/proc in the kernel, so fuse may be a good alternative but some extra 
features will be needed for fuse like 'lseek' in order to have this 
virtualization to work.

The generalization of the /proc virtualization to /sys is trivial 
because the proc virtualization framework is designed to be generic.

Preventing to umount /proc in the container (and therefore access again 
to the host /proc) may be handled by SMACK, but I think the user 
namespace is the missing piece for that.