James Morris - Upcoming conference talks on SELinux applications: sVirt and Kiosk Mode
Upcoming conference talks on SELinux applications: sVirt and Kiosk Mode|
Recently, I've been busy getting the initial cut of sVirt out, and am currently processing community feedback before issuing an update. The basic idea behind sVirt is to apply MAC label security (SELinux, Smack etc.) to Linux-based virtualization schemes such as KVM, allowing the existing OS-level security mechanisms to be re-used for process-based VMs. This is an application one of the core advantages of Linux-based virtualization, where generally, all of the Linux process management infrastructure within the kernel and wider OS may be applied to domains which run inside Linux processes. So, for MAC label security in this case, we don't need to do anything in terms of modifying kernel security mechanisms, and simply modify security policy as desired. We can focus on developing the appropriate high-level abstractions (e.g. management tool support) rather than developing a new security mechanism.
How can this be useful? In the simplest case, we can increase isolation between virtual machines by assigning them different security labels, and enforcing a MAC policy which prevents them from interacting. This helps ameliorate the increased risk arising from running domains on the same hardware where previously they may have been physically separated on different machines. This is just a start. There are plenty of interesting things which can be done once the core functionality is in place, although the initial idea is to simply provide stronger isolation to better protect domains from each other.
At an architectural level, security labeling support is being added to libvirt, a virtualization API which abstracts various aspects of virtualization including different hypervisor types, storage, networking, and with sVirt: MAC security. With sVirt integrated at the API level, security labeling support can be integrated into high-level tools via standardized and flexible abstractions. For example, when creating a new domain, the graphical virt-manager tool may include a checkbox to designate the domain as "isolated"—or perhaps just do it by default for true zeroconf.
I'll be introducing sVirt more completely at LCA next January, so if you're marching south and have interests in both security and virtualization, it might be worth popping in. I'm up against Tridge in the timeslot, so it might be an intimate session.
Next week, I'll be giving a talk on Fedora Kiosk Mode at Malaysia's inaugural developer conference, FOSS.MY. Kiosk Mode is another high-level MAC security application, where anonymous users can safely access desktop sessions and browse the internet. If you have the
xguest package installed, it Just Works, as people are starting to notice.
I've been shortlisted on the same topic at the revamped FOSS.IN a few weeks later. There's also been some discussion of a kernel development workout session, in which I'd love to participate, although it's not yet short-listed. There's also the FUDCon attached to FOSS.IN. We're hoping to have a Fedora box there running Kiosk Mode for people to play with.
Tags: bangalore, developers, events, fedora, foss.in, foss.my, fudcon, india, kuala lumpur, kvm, linux, mac, malaysia, security, selinux, svirt, virtualization
|Date:||October 31st, 2008 09:50 am (UTC)|| |
How you think, is this model also applicable to OpenVZ? Right now OpenVZ is not a part of kernel, but process of including it into mainstream kernel is on going... AFAIK some parts is already included into latest kernel. Namespaces and etc. I really want to see some day both technologies working together.
One of the specific aims of sVirt is to apply existing process-based security mechanisms to virtualization, so it will only work this way for schemes such as qemu/kvm where the VM is a process.
OpenVZ uses a different architecture where partitioning is performed via namespacing of the global system, and the above approach won't work. However, it is hoped that the API changes being made to libvirt will be general enough to support other models once the core security infrastructure is in place for them. i.e. "What is the label of this VM?" is quite general.
Making SELinux and namespace virt work would likely require significant changes to the kernel and policy constructs to support namespacing of the security mechanism itself.
|Date:||November 3rd, 2008 11:36 am (UTC)|| |
Thank you for the answer. As it's looks, there is long way to the ability of using SELinux+OpenVZ...