Académique Documents
Professionnel Documents
Culture Documents
Legal Notice
Co pyright 2012 Red Hat, Inc. The text o f and illustratio ns in this do cument are licensed by Red Hat under a Creative Co mmo ns Attributio nShare Alike 3.0 Unpo rted license ("CC-BY-SA"). An explanatio n o f CC-BY-SA is available at http://creativeco mmo ns.o rg/licenses/by-sa/3.0/. The o riginal autho rs o f this do cument, and Red Hat, designate the Fedo ra Pro ject as the "Attributio n Party" fo r purpo ses o f CC-BY-SA. In acco rdance with CCBY-SA, if yo u distribute this do cument o r an adaptatio n o f it, yo u must pro vide the URL fo r the o riginal versio n. Red Hat, as the licenso r o f this do cument, waives the right to enfo rce, and agrees no t to assert, Sectio n 4d o f CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shado wman lo go , JBo ss, MetaMatrix, Fedo ra, the Infinity Lo go , and RHCE are trademarks o f Red Hat, Inc., registered in the United States and o ther co untries. Fo r guidelines o n the permitted uses o f the Fedo ra trademarks, refer to https://fedo rapro ject.o rg/wiki/Legal:Trademark_guidelines. Linux is the registered trademark o f Linus To rvalds in the United States and o ther co untries. Java is a registered trademark o f Oracle and/o r its affiliates. XFS is a trademark o f Silico n Graphics Internatio nal Co rp. o r its subsidiaries in the United States and/o r o ther co untries. MySQL is a registered trademark o f MySQL AB in the United States, the Euro pean Unio n and o ther co untries. All o ther trademarks are the pro perty o f their respective o wners.
Abstract
This guide pro vides an o verview o f virtualizatio n security techno lo gies pro vided by Fedo ra, and pro vides reco mmendatio ns fo r securing ho sts, guests, and shared infrastructure and reso urces in virtualized enviro nments.
Preface 1. Do cument Co nventio ns 1.1. Typo graphic Co nventio ns 1.2. Pull-quo te Co nventio ns 1.3. No tes and Warnings 2. We Need Feedback! 1. Intro ductio n 1.1. Virtualized and No n-Virtualized Enviro nments 1.2. Why Virtualizatio n Security Matters 1.3. Three Way Mo del 1.4. Leveraging SELinux with sVirt 2. Ho st Security 2.1. Why Ho st Security Matters 2.2. Ho st Security Best Practices fo r Fedo ra 2.2.1. Special Co nsideratio ns fo r Public Clo ud Operato rs 3. Guest Security 3.1. Why Guest Security Matters 3.2. Guest Security Best Practices 4. sVirt 4.1. Intro ductio n 4.2. SELinux and Mandato ry Access Co ntro l (MAC) 4.3. sVirt Co nfiguratio n 4.4. sVirt Labeling 4.4.1. Types o f sVirt Labels 4.4.2. Dynamic Co nfiguratio n 4.4.3. Dynamic Co nfiguratio n with Base Labeling 4.4.4. Static Co nfiguratio n with Dynamic Reso urce Labeling 4.4.5. Static Co nfiguratio n witho ut Reso urce Labeling 5. Netwo rk Security in a Virtualized Enviro nment 5.1. Netwo rk Security Overview 5.2. Netwo rk Security Best Practices 5.2.1. Securing Co nnectivity to Spice 5.2.2. Securing Co nnectivity to Sto rage 6. Further Info rmatio n 6.1. Co ntributo rs 6.2. Other Reso urces A. Revisio n Histo ry
Preface
1. Document Conventions
This manual uses several co nventio ns to highlight certain wo rds and phrases and draw attentio n to specific pieces o f info rmatio n. In PDF and paper editio ns, this manual uses typefaces drawn fro m the Liberatio n Fo nts set. The Liberatio n Fo nts set is also used in HTML editio ns if the set is installed o n yo ur system. If no t, alternative but equivalent typefaces are displayed. No te: Red Hat Enterprise Linux 5 and later includes the Liberatio n Fo nts set by default.
Preface
yo u so ught will be highlighted in the Character Table. Do uble-click this highlighted character to place it in the Text to copy field and then click the Copy butto n. No w switch back to yo ur do cument and cho o se Edit Past e fro m the ge dit menu bar. The abo ve text includes applicatio n names; system-wide menu names and items; applicatio n-specific menu names; and butto ns and text fo und within a GUI interface, all presented in pro po rtio nal bo ld and all distinguishable by co ntext. Mono-spaced Bold Italic o r Proportional Bold Italic Whether mo no -spaced bo ld o r pro po rtio nal bo ld, the additio n o f italics indicates replaceable o r variable text. Italics deno tes text yo u do no t input literally o r displayed text that changes depending o n circumstance. Fo r example: To co nnect to a remo te machine using ssh, type ssh username@domain.name at a shell pro mpt. If the remo te machine is example.com and yo ur username o n that machine is jo hn, type ssh john@example.com. The mount -o remount file-system co mmand remo unts the named file system. Fo r example, to remo unt the /home file system, the co mmand is mount o remount /home. To see the versio n o f a currently installed package, use the rpm -q package co mmand. It will return a result as fo llo ws: package-version-release. No te the wo rds in bo ld italics abo ve username, do main.name, filesystem, package, versio n and release. Each wo rd is a placeho lder, either fo r text yo u enter when issuing a co mmand o r fo r text displayed by the system. Aside fro m standard usage fo r presenting the title o f a wo rk, italics deno tes the first use o f a new and impo rtant term. Fo r example: Publican is a DocBook publishing system.
So urce-co de listings are also set in mono-spaced roman but add syntax highlighting as fo llo ws:
package org.jboss.book.jca.ex1; import javax.naming.InitialContext; public class ExClient { public static void main(String args[]) throws Exception { InitialContext iniCtx = new InitialContext(); Object ref = iniCtx.lookup("EchoBean"); EchoHome home = (EchoHome) ref; Echo echo = home.create(); System.out.println("Created Echo"); System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); } }
Note
No tes are tips, sho rtcuts o r alternative appro aches to the task at hand. Igno ring a no te sho uld have no negative co nsequences, but yo u might miss o ut o n a trick that makes yo ur life easier.
Important
Impo rtant bo xes detail things that are easily missed: co nfiguratio n changes that o nly apply to the current sessio n, o r services that need restarting befo re an update will apply. Igno ring a bo x labeled 'Impo rtant' will no t cause data lo ss but may cause irritatio n and frustratio n.
Warning
Warnings sho uld no t be igno red. Igno ring warnings will mo st likely cause data lo ss.
2. We Need Feedback!
If yo u find a typo graphical erro r in this manual, o r if yo u have tho ught o f a way to make this manual better, we wo uld lo ve to hear fro m yo u! Please submit a repo rt in Bugzilla: http://bugzilla.redhat.co m/bugzilla/ against the pro duct Fe do ra 18. When submitting a bug repo rt, be sure to mentio n the manual's identifier: virtualization-security-guide If yo u have a suggestio n fo r impro ving the do cumentatio n, try to be as specific as po ssible when describing it. If yo u have fo und an erro r, please include the sectio n number and so me o f the surro unding text so we can find it easily.
Preface
Chapter 1. Introduction
1.1. Virtualized and No n-Virtualized Enviro nments 1.2. Why Virtualizatio n Security Matters 1.3. Three Way Mo del 1.4. Leveraging SELinux with sVirt
Virt ualize d Enviro nm e nt In a virtualized enviro nment, several o perating systems can be ho used (as "guests") within a single ho st kernel and physical ho st. The fo llo wing image represents a virtualized enviro nment:
When services are no t virtualized, machines are physically separated. Any explo it is therefo re usually co ntained to the affected machine, with the o bvio us exceptio n o f netwo rk attacks. When services are gro uped to gether in a virtualized enviro nment, extra vulnerabilities emerge in the system. If there is a security flaw in the hyperviso r that can be explo ited by a guest instance, this guest may be able to no t o nly attack the ho st, but also o ther guests running o n that ho st. This is no t theo retical;
Iso lat e Co ntro lling interactio ns between virtual machines is crucial to maintaining a high level o f security. This is pro vided in Fedo ra by sVirt. Pro t e ct Virtualized machines are no t immune to traditio nal security threats. Each virtual machine sho uld be managed with regular security co ntro ls. Lo g Virtual machines are simple to deplo y. The lack o f lo gging, change management and audit trails in a virtualized enviro nment can easily lead to a sprawling, unmanaged and insecure enviro nment.
Preface
to a sprawling, unmanaged and insecure enviro nment.
Note
The o bjective o f this guide is to explain the unique security related challenges, vulnerabilities, and so lutio ns that are present in mo st virtualized enviro nments and ho w to best address them. Ho wever, there are a number o f best practices to fo llo w when securing a Fedo ra system that apply regardless o f whether the system is a standalo ne, virtualizatio n ho st, o r guest instance. These best practices include pro cedures such as system updates, passwo rd security, encryptio n, and firewall co nfiguratio n. This info rmatio n is discussed in mo re detail in the Fedora Security Guide which can be fo und at http://do cs.fedo rapro ject.o rg.
10
Preface
bo th between the ho st and guest as well as between guests, is critical due to the threat o f malicio us guests, as well as the requirements o n custo mer data co nfidentiality and integrity acro ss the virtualizatio n infrastructure. In additio n to the Fedo ra virtualizatio n best practices previo usly listed, public clo ud o perato rs sho uld also co nsider the fo llo wing items: Disallo w any direct hardware access fro m the guest. PCI, USB, FireWire, Thunderbo lt, eSATA and o ther device passthro ugh mechanisms no t o nly make management difficult, but o ften rely o n the underlying hardware to enfo rce separatio n between the guests. Netwo rk traffic sho uld be separated such that the clo ud o perato r's private management netwo rk is iso lated fro m the custo mer guest netwo rk, helping to ensure that the guests can no t access the ho st systems o ver the netwo rk. The netwo rk sho uld be further iso lated such that custo mer guest systems run in a private, virtualized netwo rk so that o ne custo mer can no t access ano ther custo mer's guest systems directly via the clo ud pro vider's internal netwo rk.
11
Chapter 4. sVirt
4.1. Intro ductio n 4.2. SELinux and Mandato ry Access Co ntro l (MAC) 4.3. sVirt Co nfiguratio n 4.4. sVirt Labeling 4.4.1. Types o f sVirt Labels 4.4.2. Dynamic Co nfiguratio n 4.4.3. Dynamic Co nfiguratio n with Base Labeling 4.4.4. Static Co nfiguratio n with Dynamic Reso urce Labeling 4.4.5. Static Co nfiguratio n witho ut Reso urce Labeling
4.1. Introduction
Since virtual machines under KVM are implemented as Linux pro cesses, KVM leverages the standard Linux security mo del to pro vide iso latio n and reso urce co ntro ls. The Linux kernel includes SELinux (Security-Enhanced Linux), a pro ject develo ped by the US Natio nal Security Agency to add mandato ry access co ntro l (MAC), multi-level security (MLS) and multi-catego ry security (MCS) thro ugh a flexible and custo mizable security po licy. SELinux pro vides strict reso urce iso latio n and co nfinement fo r pro cesses running o n to p o f the Linux kernel, including virtual machine pro cesses. The sVirt pro ject builds upo n SELinux to further facilitate virtual machine iso latio n and co ntro lled sharing. Fo r example, fine-grained permissio ns co uld be applied to gro up virtual machines to gether to share reso urces. Fro m a security po int o f view, the hyperviso r is a tempting target fo r attackers, as a co mpro mised hyperviso r co uld lead to the co mpro mise o f all virtual machines running o n the ho st system. Integrating SELinux into the virtualizatio n techno lo gies helps impro ve the security o f the hyperviso r against malicio us virtual machines trying to gain access to the ho st system o r o ther virtual machines. Refer to the fo llo wing image which represents iso lated guests, limiting the ability fo r a co mpro mised hyperviso r (o r guest) to launch further attacks, o r to extend to ano ther instance:
12
Preface
implementatio ns suppo rted by sVirt to intero perate.
system_u:o bject_r:svirt_image_t:MCS1
Virtual Machine Shared Read/Write Co ntent Virtual Machine Shared Shared Read Only co ntent Virtual Machine Image
system_u:o bject_r:svirt_image_t:s0
System default label used when an image exits. No svirt_t virtual pro cesses are allo wed to read files/devices with this label.
13
In this example, the qemu-kvm pro cess has a base label o f system_u:system_r:svirt_t:s0. The libvirt system has generated a unique MCS label o f c87,c520 fo r this pro cess. The base label and the MCS label are co mbined to fo rm the co mplete security label fo r the pro cess. Likewise, libvirt takes the same MCS label and base label to fo rm the image label. This image label is then auto matically applied to all ho st files that the VM is required to access, such as disk images, disk devices, PCI devices, USB devices, and kernel/initrd files. Each pro cess is iso lated fro m o ther virtual machines with different labels. The fo llo wing example sho ws the virtual machine's unique security label (with a co rrespo nding MCS label o f c87,c520 in this case) as applied to the guest disk image file in /var/lib/libvirt/images:
# ls -lZ /var/lib/libvirt/images/* system_u:object_r:svirt_image_t:s0:c87,c520 image1
The fo llo wing example sho ws dynamic labeling in the XML co nfiguratio n fo r the guest:
<seclabel type='dynamic' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_t:s0:c87,c520</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c87,c52 0</imagelabel> </seclabel>
14
Preface
specific label, including the MCS/MLS field, fo r a virtual machine. Administrato rs who run statically-labeled virtual machines are respo nsible fo r setting the co rrect label o n the image files. The virtual machine will always be started with that label, and the sVirt system will never mo dify the label o f a statically-labelled virtual machine's co ntent. The fo llo wing guest XML co nfiguratio n demo nstrates an example o f this scenario :
<seclabel type='static' model='selinux' relabel='no'> <label>system_u:system_r:svirt_custom_t:s0:c87,c520</l abel> </seclabel>
15
6.1. Contributors
Thanks go to the fo llo wing peo ple fo r enabling the creatio n o f this guide: Paul Mo o re - Red Hat Engineering Kurt Seifried - Red Hat Engineering David Jo rm - Red Hat Engineering
Revision History
Re visio n 0.1-4 Mo n Aug 27 2012 prepare fo r draft publish. Sco t t Radvan Re visio n 0.1-03 T hu Aug 16 2012 Sco t t Radvan Expand IPL mo del. Fix .ent file to sho w co rrect BZ co mpo nent fo r Fedo ra. Re visio n 0.1-02 T hu Aug 16 2012 Fo rk fro m Red Hat guide. Sco t t Radvan