Fedora 18 Virtualization Security Guide en US

Published on January 2017 | Categories: Documents | Downloads: 39 | Comments: 0 | Views: 186
of 15
Download PDF   Embed   Report

Comments

Content

Fedora 18 Virtualization Security Guide

1

Fedora 18 Virtualization Security Guide
Virtualization Documentation Edition 1.0

Red Hat Engineering Co ntent Services

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 n–Share 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.

2

Virtualization Security Guide

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

Fedora 18 Virtualization Security Guide

3

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.

1.1. Typographic Convent ions
Fo ur typo graphic co nventio ns are used to call attentio n to specific wo rds and phrases. These co nventio ns, and the circumstances they apply to , are as fo llo ws. Mono-spaced Bold Used to highlight system input, including shell co mmands, file names and paths. Also used to highlight keycaps and key co mbinatio ns. Fo r example: To see the co ntents o f the file my_next_bestselling_novel in yo ur current wo rking directo ry, enter the cat my_next_bestselling_novel co mmand at the shell pro mpt and press Enter to execute the co mmand. The abo ve includes a file name, a shell co mmand and a keycap, all presented in mo no -spaced bo ld and all distinguishable thanks to co ntext. Key co mbinatio ns can be distinguished fro m keycaps by the hyphen co nnecting each part o f a key co mbinatio n. Fo r example: Press Enter to execute the co mmand. Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to yo ur X-Windo ws sessio n. The first paragraph highlights the particular keycap to press. The seco nd highlights two key co mbinatio ns (each a set o f three keycaps with each set pressed simultaneo usly). If so urce co de is discussed, class names, metho ds, functio ns, variable names and returned values mentio ned within a paragraph will be presented as abo ve, in mono-spaced bold. Fo r example: File-related classes include filesystem fo r file systems, file fo r files, and dir fo r directo ries. Each class has its o wn asso ciated set o f permissio ns. Pro po rt io nal Bo ld This deno tes wo rds o r phrases enco untered o n a system, including applicatio n names; dialo g bo x text; labeled butto ns; check-bo x and radio butto n labels; menu titles and sub-menu titles. Fo r example: Cho o se Syst e m → Pre fe re nce s → Mo use fro m the main menu bar to launch Mo use Pre fe re nce s. In the Buttons tab, click the Left-handed mouse check bo x and click Close to switch the primary mo use butto n fro m the left to the right (making the mo use suitable fo r use in the left hand). To insert a special character into a ge dit file, cho o se Applicat io ns → Acce sso rie s → Charact e r Map fro m the main menu bar. Next, cho o se Se arch → Find… fro m the Charact e r Map menu bar, type the name o f the character in the Search field and click Next. The character

4

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 [email protected] 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 [email protected]. 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.

1.2. Pull-quot e Convent ions
Terminal o utput and so urce co de listings are set o ff visually fro m the surro unding text. Output sent to a terminal is set in mono-spaced roman and presented thus:
books Desktop photos stuff svn books_tests Desktop1 scripts svgs documentation downloads drafts images mss notes

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")); } }

Fedora 18 Virtualization Security Guide

5

1.3. Not es and Warnings
Finally, we use three visual styles to draw attentio n to info rmatio n that might o therwise be o verlo o ked.

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.

6

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

1.1. Virtualized and Non-Virtualized Environments
A virtualized enviro nment presents the o ppo rtunity fo r bo th the disco very o f new attack vecto rs and the refinement o f existing explo its which may no t previo usly have presented value to an attacker. It is therefo re impo rtant to take steps to ensure the security o f bo th the physical ho sts and the guests running o n them when creating and maintaining virtual machines. No n-Virt ualize d Enviro nm e nt In a no n-virtualized enviro nment, ho sts are separated fro m each o ther physically and each ho st has a self-co ntained enviro nment, co nsisting o f services such as a web server, o r a DNS server. These services co mmunicate directly to their o wn user space, ho st kernel and physical ho st, o ffering their services directly to the netwo rk. The fo llo wing image represents a no n-virtualized enviro nment:

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;

Fedora 18 Virtualization Security Guide
attacks already exist o n hyperviso rs. These attacks can extend beyo nd the guest instance and co uld expo se o ther guests to attack.

7

1.2. Why Virtualization Security Matters
Deplo ying virtualizatio n in yo ur infrastructure pro vides many benefits but can also intro duce new risks. Virtualized reso urces and services sho uld be deplo yed with the fo llo wing security co nsideratio ns: The ho st/hyperviso r beco me prime targets; in effect, they are o ften a single po int o f failure fo r guests and data. Virtual machines can interfere with each o ther in undesirable ways. Reso urces and services can beco me difficult to track and maintain; with rapid deplo yment o f virtualized systems co mes an increased need fo r management o f reso urces, including sufficient patching, mo nito ring and maintenance. There may be a lack o f kno wledge, gaps in skill sets, and minimal experience amo ng technical staff. This is o ften a gateway to vulnerabilities. Reso urces such as sto rage can be spread acro ss, and dependent upo n, several machines. This can lead to o verly co mplex enviro nments, and po o rly-managed and maintained systems. Virtualizatio n do es no t remo ve any o f the traditio nal security risks present in yo ur enviro nment; the entire so lutio n stack, no t just the virtualizatio n layer, must be secured. This guide aims to assist yo u in mitigating yo ur security risks by o ffering a number o f virtualizatio n best practices fo r Fedo ra that will help yo u secure yo ur virtualized infrastructure.

1.3. Three Way Model
A three-way co nceptual mo del, CIA (Co nfidentiality, Integrity, Availability) is o ften used in general co mputing security. A similar mo del can be presented in additio n to this mo del when analyzing virtualizatio n security: IPL (Iso late, Pro tect, Lo g), as sho wn in the fo llo wing diagram:

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.

8

Preface
to a sprawling, unmanaged and insecure enviro nment.

1.4. Leveraging SELinux with sVirt
sVirt integrates virtualizatio n into the existing security framewo rk pro vided by SELinux (Security-Enhanced Linux), applying Mandatory Access Control (MAC) to virtual machines. The main o bjective o f sVirt is to pro tect ho sts and guests fro m attacks via security vulnerabilities in the hyperviso r. SELinux secures a system by applying access po licy acro ss different pro cesses. sVirt extends this capability to ho sts and guests by treating each guest as a pro cess, allo wing administrato rs to apply similar po licies designed to prevent malicio us guests fro m accessing restricted reso urces. Fo r mo re info rmatio n o n sVirt, refer to Chapter 4, sVirt.

Fedora 18 Virtualization Security Guide

9

Chapter 2. Host 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

2.1. Why Host Security Matters
When deplo ying virtualizatio n techno lo gies, the security o f the ho st sho uld be paramo unt. The Fedo ra ho st system is respo nsible fo r managing and co ntro lling access to the physical devices, sto rage and netwo rk as well as all virtualized guests themselves. If the ho st system were to be co mpro mised, no t o nly wo uld the ho st system be vulnerable, but the guests and their data wo uld be also . Virtualized guests are o nly as secure as their ho st system; securing the Fedo ra ho st system is the first step to wards ensuring a secure virtualizatio n platfo rm.

2.2. Host Security Best Practices for Fedora
With ho st security being such a critical part o f a secure virtualizatio n infrastructure, the fo llo wing best practices sho uld serve as a starting po int fo r securing a Fedo ra ho st system: Run o nly the services necessary to suppo rt the use and management o f yo ur guest systems. If yo u need to pro vide additio nal services, such as file o r print services, yo u sho uld co nsider running tho se services in a Fedo ra guest. Limit direct access to the system to o nly tho se users who have a need to manage the system. Co nsider disallo wing shared ro o t access and instead use to o ls such as sudo to grant privileged access to administrato rs based o n their administrative ro les. Ensure that SELinux is co nfigured pro perly fo r yo ur installatio n and is o perating in enfo rcing mo de. Besides being a go o d security practice, the advanced virtualizatio n security functio nality pro vided by sVirt relies o n SELinux. Refer to Chapter 4, sVirt fo r mo re info rmatio n o n SELinux and sVirt. Ensure that any remo te management o f the system takes place o nly o ver secured netwo rk channels. To o ls such as SSH and netwo rk pro to co ls such as TLS o r SSL pro vide bo th authenticatio n and data encryptio n to ensure that o nly appro ved administrato rs can manage the system remo tely. Ensure that the firewall is co nfigured pro perly fo r yo ur installatio n and is activated at bo o t. Only tho se netwo rk po rts needed fo r the use and management o f the system sho uld be allo wed. Refrain fro m granting guests direct access to entire disks o r blo ck devices (fo r example, /dev/sdb); instead, yo u sho uld use partitio ns (fo r example, /dev/sdb1) o r LVM vo lumes fo r guest sto rage.

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.

2.2.1. Special Considerat ions for Public Cloud Operat ors
Public clo ud service pro viders are expo sed to a number o f security risks beyo nd that o f the traditio nal virtualizatio n user. Virtual guest iso latio n,

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.

Chapter 3. Guest Security
3.1. Why Guest Security Matters 3.2. Guest Security Best Practices

3.1. Why Guest Security Matters
While the security o f the ho st system is critical in ensuring the security o f the guests running o n the ho st, it do es no t remo ve the need fo r pro perly securing the individual guest machines. All o f the security risks asso ciated with a co nventio nal, no n-virtualized system still exist when the system is run as a virtualized guest. Any reso urces accessible to the guest system, such as critical business data o r sensitive custo mer info rmatio n, co uld be made vulnerable if the guest system were to be co mpro mised.

3.2. Guest Security Best Practices
All o f the best practices fo r securing a Fedo ra system do cumented in the Fedora Security Guide apply to the co nventio nal, no n-virtualized systems as well as tho se systems installed as a virtualized guest. Ho wever, there are a few security practices which are o f critical impo rtance when running in a virtualized enviro nment: With all management o f the guest likely taking place remo tely, ensure that the management o f the system takes place o nly o ver secured netwo rk channels. To o ls such as SSH and netwo rk pro to co ls such as TLS o r SSL pro vide bo th authenticatio n and data encryptio n to ensure that o nly appro ved administrato rs can manage the system remo tely. So me virtualizatio n techno lo gies use special guest agents o r drivers to enable so me virtualizatio n specific features. Ensure that these agents and applicatio ns are secured using the standard Fedo ra security features, e.g. SELinux. In virtualized enviro nments there is a greater risk o f sensitive data being accessed o utside the pro tectio n bo undaries o f the guest system. Pro tect sto red sensitive data using encryptio n to o ls such as dm-crypt and GnuPG; altho ugh special care needs to be taken to ensure the co nfidentiality o f the encryptio n keys.

Fedora 18 Virtualization Security Guide

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:

4.2. SELinux and Mandatory Access Control (MAC)
Security-Enhanced Linux (SELinux) is an implementatio n o f MAC in the Linux kernel, checking fo r allo wed o peratio ns after standard discretio nary access co ntro ls (DAC) are checked. SELinux can enfo rce a user custo mizable security po licy o n running pro cesses and their actio ns, including their attempts to access file system o bjects. Enabled by default in Fedo ra, SELinux limits the sco pe o f po tential damage that can result fro m the explo itatio n o f vulnerabilities in applicatio ns and system services, such as the hyperviso r. sVirt integrates with libvirt, a virtualizatio n management abstractio n layer, to pro vide a MAC framewo rk fo r virtual machines. This architecture allo ws all virtualizatio n platfo rms suppo rted by libvirt and all MAC

12

Preface
implementatio ns suppo rted by sVirt to intero perate.

4.3. sVirt Configuration
SELinux Bo o leans are variables that can be to ggled o n o r o ff, quickly enabling o r disabling features o r o ther special co nditio ns. The fo llo wing table sho ws the SELinux Bo o lean values that affect KVM when launched by libvirt. KVM SELinux Bo o le ans SELinux Bo o le an virt_use_co mm virt_use_fusefs virt_use_nfs virt_use_samba virt_use_sanlo ck virt_use_sysfs virt_use_usb virt_use_xserver De script io n Allo w virt to use serial/parallel co mmunicatio n po rts. Allo w virt to read FUSE mo unted files. Allo w virt to manage NFS mo unted files. Allo w virt to manage CIFS mo unted files. Allo w sanlo ck to manage virt lib files. Allo w virt to manage device co nfiguratio n (PCI). Allo w virt to use USB devices. Allo w virtual machine to interact with the X Windo w System.

4.4. sVirt Labeling
Like o ther services under the pro tectio n o f SELinux, sVirt uses pro cess based mechanisms, labels and restrictio ns to pro vide extra security and co ntro l o ver guest instances. Labels are applied auto matically to reso urces o n the system based o n the currently running virtual machines (dynamic), but can also be manually specified by the administrato r (static), to meet any specific requirements that may exist.

4.4.1. Types of sVirt Labels
The fo llo wing table o utlines the different sVirt labels that can be assigned to reso urces such as virtual machine pro cesses, image files and shared co ntent: T able 4.1. sVirt Labe ls T ype Virtual Machine Pro cesses SELinux Co nt e xt system_u:system_r:svirt_t:MCS1 De script io n/Effe ct MCS1 is a rando mly selected field. Currently appro ximately 500,000 labels are suppo rted. Only svirt_t pro cesses with the same MCS1 fields are able to read/write these image files and devices. All svirt_t pro cesses are allo wed to write to the svirt_image_t:s0 files and devices. All svirt_t pro cesses are able to read files/devices with this label.

Virtual Machine Image

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_u:o bject_r:svirt_co ntent_t:s0

system_u:o bject_r:virt_co ntent_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.

Fedora 18 Virtualization Security Guide

13

4.4.2. Dynamic Configurat ion
Dynamic label co nfiguratio n is the default labeling o ptio n when using sVirt with SELinux. Refer to the fo llo wing example which demo nstrates dynamic labeling:
# ps -eZ | grep qemu-kvm system_u:system_r:svirt_t:s0:c87,c520 27950 ? 00:00:17 qemu-kvm

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>

4.4.3. Dynamic Configurat ion wit h Base Labeling
To o verride the default base security label in dynamic mo de, the <baselabel> o ptio n can be co nfigured manually in the XML guest co nfiguratio n, as sho wn in this example:
<seclabel type='dynamic' model='selinux' relabel='yes'> <baselabel>system_u:system_r:svirt_custom_t:s0</basela bel> <label>system_u:system_r:svirt_custom_t:s0:c87,c520</l abel> <imagelabel>system_u:object_r:svirt_image_t:s0:c87,c52 0</imagelabel> </seclabel>

4.4.4. St at ic Configurat ion wit h Dynamic Resource Labeling
So me applicatio ns require full co ntro l o ver the generatio n o f security labels but still require libvirt to take care o f reso urce labeling. The fo llo wing guest XML co nfiguratio n demo nstrates an example o f static co nfiguratio n with dynamic reso urce labeling:
<seclabel type='static' model='selinux' relabel='yes'> <label>system_u:system_r:svirt_custom_t:s0:c87,c520</l abel> </seclabel>

4.4.5. St at ic Configurat ion wit hout Resource Labeling
Primarily used in MLS (multi-level security) o r o therwise strictly co ntro lled enviro nments, static co nfiguratio n witho ut reso urce relabeling is po ssible. Static labels allo w the administrato r to select a

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>

Chapter 5. Network Security in a Virtualized Environment
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

5.1. Network Security Overview
In almo st all situatio ns, the netwo rk is the o nly way to access systems, applicatio ns and management interfaces. As netwo rking plays such a critical ro le in the management o f virtualized systems and the availability o f their ho sted applicatio ns, it is very impo rtant to ensure that the netwo rk channels bo th to and fro m the virtualized systems are secure. Securing the netwo rk allo ws administrato rs to co ntro l access and pro tect sensitive data fro m info rmatio n leaks and tampering.

5.2. Network Security Best Practices
Netwo rk security is a critical part o f a secure virtualizatio n infrastructure. Refer to the fo llo wing best practices fo r securing the netwo rk: Ensure that remo te management o f the system takes place o nly o ver secured netwo rk channels. To o ls such as SSH and netwo rk pro to co ls such as TLS o r SSL pro vide bo th authenticatio n and data encryptio n to assist with secure and co ntro lled access to systems. Ensure that guest applicatio ns transferring sensitive data do so o ver secured netwo rk channels. If pro to co ls such as TLS o r SSL are no t available, co nsider using IPsec. Co nfigure firewalls and ensure they are activated at bo o t. Only tho se netwo rk po rts needed fo r the use and management o f the system sho uld be allo wed. Test and review firewall rules regularly.

5.2.1. Securing Connect ivit y t o Spice
The Spice remo te deskto p pro to co l suppo rts SSL/TLS which sho uld be enabled fo r all o f the Spice co mmunicatio n channels (main, display, inputs, curso r, playback, reco rd).

5.2.2. Securing Connect ivit y t o St orage
Yo u can co nnect virtualized systems to netwo rked sto rage in many different ways. Each appro ach presents different security benefits and co ncerns, ho wever the same security principles apply to each: authenticate the remo te sto re po o l befo re use, and pro tect the co nfidentiality and integrity o f the data while it is being transferred. The data must also remain secure while it is sto red. It is co nsidered a best practice to encrypt and/o r digitally sign the data befo re sto ring it.

Fedora 18 Virtualization Security Guide

15

Chapter 6. Further Information
6.1. Co ntributo rs 6.2. Other Reso urces

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

6.2. Other Resources
SELinux and sVirt Further info rmatio n o n SELinux and sVirt: Main SELinux website: http://www.nsa.go v/research/selinux/index.shtml. SELinux do cumentatio n: http://www.nsa.go v/research/selinux/do cs.shtml. Main sVirt website: http://selinuxpro ject.o rg/page/SVirt. Dan Walsh's blo g: http://danwalsh.livejo urnal.co m/. The uno fficial SELinux FAQ: http://www.crypt.gen.nz/selinux/faq.html. Virt ualizat io n Se curit y Further info rmatio n o n virtualizatio n security: NIST (Natio nal Institute o f Standards and Techno lo gy) full virtualizatio n security guidelines: http://www.nist.go v/itl/csd/virtual020111.cfm.

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

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close