From Fedora Project Wiki
-->dwalsh (n=dwalsh@c-24-60-234-36.hsd1.ma.comcast.net) has joined #fedora-classroom | Nov 17 07:14 | |
-->mj0vy (n=mj0vy@redhat/mj0vy) has joined #fedora-classroom | Nov 17 07:14 | |
dwalsh | hello | Nov 17 07:14 |
---|---|---|
delhage | hi :) | Nov 17 07:14 |
inode0 | \o/ | Nov 17 07:14 |
dwalsh | Sorry I got carried away at other stuff and forgot to do the class. | Nov 17 07:15 |
zer0c00l | lol | Nov 17 07:16 |
dwalsh | I am just going to go over the presentation at http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/svirt.pdf | Nov 17 07:16 |
dwalsh | When I was in college if the Prof was 15 minutes late, we figured the class was cancelled. | Nov 17 07:17 |
<--mintos has quit (Read error: 110 (Connection timed out)) | Nov 17 07:17 | |
-->Josh_Borke (n=jk275@WoWUIDev/WoWInterface/LegoBlock/joshborke) has joined #fedora-classroom | Nov 17 07:17 | |
dwalsh | So if you are still here, I will go ahead. | Nov 17 07:17 |
*mj0vy is here. | Nov 17 07:17 | |
-->mintos (n=mvaliyav@nat/redhat/x-vtilyclatqdvgyav) has joined #fedora-classroom | Nov 17 07:17 | |
*zer0c00l is here | Nov 17 07:17 | |
delhage | I think you made it by one minute ;) | Nov 17 07:17 |
inode0 | we would have waited longer for you to show up dwalsh :) | Nov 17 07:17 |
dgrift | is here | Nov 17 07:18 |
dwalsh | Ok lets start | Nov 17 07:18 |
dwalsh | Slide 2 | Nov 17 07:18 |
dwalsh | Having a hard time getting setup | Nov 17 07:19 |
delhage | whouldn't we turn on the logging? nirik? | Nov 17 07:19 |
zer0c00l | what happened to meet bot? | Nov 17 07:20 |
delhage | shouldn't* | Nov 17 07:20 |
zer0c00l | yeah! | Nov 17 07:20 |
dwalsh | Here we go. | Nov 17 07:21 |
dwalsh | The hottest thing in Computer shows right now is Virtualization. | Nov 17 07:21 |
dwalsh | It seems to be the nervana. Every thing is going to be fixed by virtualization. | Nov 17 07:21 |
dwalsh | Red Hat, Microsoft, VMWare | Nov 17 07:22 |
dwalsh | and their allies are pushing virtualization | Nov 17 07:22 |
dwalsh | Proponents are suggesting that you will get great benefits like | Nov 17 07:22 |
dwalsh | Power savings | Nov 17 07:23 |
dwalsh | Ease of Maintenance | Nov 17 07:23 |
dwalsh | Cost savings in Power, Real Estate | Nov 17 07:23 |
dwalsh | Etc | Nov 17 07:23 |
-->londo_ (n=georgiou@82.133.49.59) has joined #fedora-classroom | Nov 17 07:23 | |
dwalsh | Next slide | Nov 17 07:23 |
dwalsh | Before Virtualization | Nov 17 07:24 |
dwalsh | We have a pretty good story from a security point of view. | Nov 17 07:24 |
dwalsh | If one machine gets compromized, we have isolation | Nov 17 07:24 |
dwalsh | based on the network. | Nov 17 07:24 |
dwalsh | We have excellent tools to watch for network attacks. | Nov 17 07:25 |
dwalsh | Packet analysys, | Nov 17 07:25 |
dwalsh | for example | Nov 17 07:25 |
dwalsh | And we have good tools like firewalls and SELinux to protect secondary machines from being compromized | Nov 17 07:25 |
dwalsh | This is a well understood problem. | Nov 17 07:25 |
dwalsh | We have been dealing with this type of attack for many years. | Nov 17 07:26 |
dwalsh | Next slide | Nov 17 07:26 |
dwalsh | In a virtualized system the network isolation goes away. | Nov 17 07:26 |
dwalsh | Since you are running multiple operating systems on a machine at once. | Nov 17 07:27 |
dwalsh | In Linux KVM each one of these virtual machines is one or more processes running on the host machine. | Nov 17 07:27 |
<--shoonya has quit (Read error: 104 (Connection reset by peer)) | Nov 17 07:27 | |
dwalsh | I have talked to desktop virtualization people who are talking about 100-1000 VMs running simultaneously on the same machine. | Nov 17 07:28 |
-->shoonya (n=unknown@122.166.8.199) has joined #fedora-classroom | Nov 17 07:28 | |
dwalsh | Next slide. | Nov 17 07:28 |
dwalsh | What can possibly go wrong..... | Nov 17 07:28 |
dwalsh | Flawed Hypervisor. | Nov 17 07:28 |
dwalsh | Flawed hypervisor: | Nov 17 07:29 |
dwalsh | Malicious guest breaks out, attacks other guests or host. Now all of your systems are | Nov 17 07:29 |
dwalsh | susceptible to a broken hypervisor, no Network to protect you. | Nov 17 07:29 |
dwalsh | If you rely on standard unix protections. Like UID, currently virtual machines are running as root. | Nov 17 07:30 |
dwalsh | But they are moving to run as the UID qemu? | Nov 17 07:30 |
dwalsh | Is this better? | Nov 17 07:30 |
dwalsh | Maybe/Maybe not. | Nov 17 07:30 |
dwalsh | If you run all the virtual machines as the same UID you might protect the host machine but you will not protect the virtual machines from each other. | Nov 17 07:31 |
dwalsh | Next slide | Nov 17 07:31 |
dwalsh | So lets talk about Hypervisor Vulnerabilities | Nov 17 07:32 |
dwalsh | They are not Theoretical | Nov 17 07:32 |
dwalsh | It is an evolving field. | Nov 17 07:32 |
dwalsh | If you went to a Black Hat convention, this is one of the biggest topics being discussed. | Nov 17 07:32 |
dwalsh | Why? | Nov 17 07:32 |
dwalsh | Remember the Jesse James quote about Why he robbed the banks. | Nov 17 07:33 |
dwalsh | That is where the money is. | Nov 17 07:33 |
dwalsh | There are potentially huge payoffs | Nov 17 07:33 |
dwalsh | Finally Xen has already been compromised | Nov 17 07:34 |
dwalsh | next slide | Nov 17 07:34 |
dwalsh | The paper referenced in this slide explains how hackers broke out of a xen virtual machine to take over a RHEL5 box. | Nov 17 07:34 |
dwalsh | And if you notice the highlight, they explain how they got around SELinux :^( | Nov 17 07:35 |
dwalsh | The sad part is I knew the SELinux protections on Xen were of limited value when I wrote them. | Nov 17 07:35 |
dwalsh | The problem was when we were writing RHEL5 and Xen policy we required the administrators to label disk/images with a label of xen_image_t. | Nov 17 07:36 |
dwalsh | So if you stored you images in /var/lib/xem/images they would get the correct label xen_image_t and the xen_t would be able to manage them. | Nov 17 07:37 |
dwalsh | BUT... | Nov 17 07:37 |
dwalsh | If you wanted to setup a xen image on a physical disk node using lvm or iscsi. | Nov 17 07:37 |
dwalsh | You would have to set up the labeling on the node to be xen_image_t. | Nov 17 07:38 |
dwalsh | People using xen like this were regularly hitting this problem that xen_t was not able to write to fixed_disk_device_t:blk_file | Nov 17 07:38 |
dwalsh | Which is the default label of physical disk device nodes. | Nov 17 07:38 |
dwalsh | Xen and ultimately RHEL Management decided that SELinux was breaking Xen and we had to allow this to get the product complete. | Nov 17 07:39 |
dwalsh | Well I relented and allowed xend_t to write fixed_disk_device_t and this is how the compromized xen person broke out of SELinux confinement. | Nov 17 07:40 |
dwalsh | If I can write to the physical disk label I can write anywhere on any disk. | Nov 17 07:40 |
dwalsh | I vowed we would not do this with kvm virtualizaion. | Nov 17 07:41 |
dwalsh | More on that later. | Nov 17 07:41 |
dwalsh | Next slide | Nov 17 07:41 |
-->rprice (n=0x83@nat/redhat/x-isobbldffwawxflg) has joined #fedora-classroom
|
Nov 17 07:41 | |
dwalsh | This slide shows what happens when a hypervisor is compromized | Nov 17 07:42 |
dwalsh | The virtual machine in this picture has a web app problem that allows the cracker to get full control of the machine. | Nov 17 07:42 |
dwalsh | The cracker now figures out that he is running in a virtual machine and uses the hypervisor compromize to attack the host. | Nov 17 07:43 |
dwalsh | Finally he also attacks other virtual machine on the host. | Nov 17 07:43 |
dwalsh | Realize that the other virtual machines do not even need to be running. | Nov 17 07:43 |
dwalsh | The Cracker could simply attack the other virtual images that this host machine can write too. | Nov 17 07:44 |
dwalsh | libguestfs makes this much easier... | Nov 17 07:44 |
dwalsh | next slide | Nov 17 07:44 |
dwalsh | This is the Who is the weakest link slide. | Nov 17 07:44 |
dwalsh | Red Hat prides itself on being the most secure Main Stream Operating System. | Nov 17 07:45 |
dwalsh | Linux prides itself as being the most secure Operating System | Nov 17 07:45 |
dwalsh | But now we are going to run Red Hat, Microsoft, Solaris, Suse ... | Nov 17 07:46 |
dwalsh | All on the same host. | Nov 17 07:46 |
dwalsh | Any one of these can get compromised and then attack the hypervisor. | Nov 17 07:46 |
dwalsh | So you are only as secure as the Weakest OS that you are running in your host | Nov 17 07:47 |
dwalsh | next slide | Nov 17 07:47 |
dwalsh | Now lets look at Cloud | Nov 17 07:47 |
dwalsh | Amazone, Google and hundreds of smaller entities are telling cloud is the future. | Nov 17 07:48 |
dwalsh | Destroy your datacenters and just let us run them in the cloud. | Nov 17 07:48 |
dwalsh | Reminds me of a childrens story | Nov 17 07:48 |
dwalsh | Next slide | Nov 17 07:48 |
dwalsh | Hansel and Gretyl | Nov 17 07:48 |
dwalsh | Nice house on the outside, but beware of whats inside | Nov 17 07:49 |
dwalsh | next slide | Nov 17 07:49 |
dwalsh | My view of cloud | Nov 17 07:49 |
dwalsh | Why should I trust Amazon? Google? | Nov 17 07:49 |
dwalsh | next slide | Nov 17 07:49 |
dwalsh | You do not know what virtual machine will be running next to you. | Nov 17 07:50 |
dwalsh | Just to highlight this. What happens if Coke and Pepsi get the same host? | Nov 17 07:50 |
dwalsh | BTW I have given this presentation before and usually marketing makes me say Soda Company A and B | Nov 17 07:50 |
dwalsh | But I think you get the point. | Nov 17 07:51 |
dwalsh | If you have valuable information and you put it out on the cloud. | Nov 17 07:51 |
dwalsh | You need to worry about the cloud company being secure and you have to worry about every virtual machine that runs with your vm. | Nov 17 07:51 |
dwalsh | In the cloud case, crackers do not need to break into one of the virtual machines. | Nov 17 07:52 |
dwalsh | If they know about a hypervisor vulnerability all they need to do is pay amazon for a host machine with root access and | Nov 17 07:52 |
dwalsh | start it up. | Nov 17 07:52 |
dwalsh | Break through the Hypervisor Vulnerabiltiy and see what virtual machines you can attack. | Nov 17 07:53 |
dwalsh | Sounds like fun... | Nov 17 07:53 |
dwalsh | Next slide | Nov 17 07:53 |
dwalsh | Enter SELinux.. | Nov 17 07:53 |
dwalsh | As I have written before SELinux is all about labeling. | Nov 17 07:53 |
dwalsh | It puts labels on processes and labels on objects like files and nodes. | Nov 17 07:54 |
dwalsh | It then writes rules that say how a process label can interact with a file label. | Nov 17 07:54 |
dwalsh | Or other process labels. | Nov 17 07:54 |
dwalsh | So Processes get labels | Nov 17 07:54 |
dwalsh | In Linux/KVM virtual machines are just processes. | Nov 17 07:55 |
dwalsh | Interesting | Nov 17 07:55 |
dwalsh | Files/Devices get labels | Nov 17 07:55 |
dwalsh | In Linux/KVM Virtual Images are stored in files of physical devices | Nov 17 07:55 |
dwalsh | So they get labels | Nov 17 07:55 |
dwalsh | So SELinux and Linux/KVM are a great match. | Nov 17 07:56 |
dwalsh | So you can label guest process as A and an image file as | Nov 17 07:56 |
dwalsh | B and write rules that say Process A can Read/Write File B. Similarly I could create a | Nov 17 07:56 |
dwalsh | separate guest labeled C and a separate image labeled D, and a rule that says | Nov 17 07:56 |
dwalsh | Process C can Read/Write File D. | Nov 17 07:56 |
dwalsh | But if there is no rule that allows process A to access image D, the kernel will prevent | Nov 17 07:56 |
dwalsh | process A from touching image D, even if the process A is running as root. | Nov 17 07:56 |
dwalsh | next slide | Nov 17 07:57 |
dwalsh | svirt in a nutshell is to isolate guest images using MAC (SELinux) to contain hypervisor breaches. | Nov 17 07:57 |
dwalsh | But what about the xen problem we discussed earlier. | Nov 17 07:58 |
dwalsh | Sys admins do not want to do all this labeling. They don't understand it and they get it wrong. Dumb Humans. | Nov 17 07:58 |
dwalsh | With svirt we allow the computer to do the labeling | Nov 17 07:58 |
dwalsh | sVirt is a component of libvirtd | Nov 17 07:59 |
dwalsh | libvirtd knows all the files involved with a virtual machine | Nov 17 07:59 |
dwalsh | Since it starts the virtual machines | Nov 17 07:59 |
dwalsh | it can label all of the content | Nov 17 07:59 |
dwalsh | before starting the virtual machine | Nov 17 07:59 |
dwalsh | It can relabel the content when the virtual machine completes | Nov 17 08:00 |
dwalsh | We can take the human element out of the equation. | Nov 17 08:00 |
dwalsh | SELinux simplified. | Nov 17 08:00 |
dwalsh | Next slide | Nov 17 08:00 |
dwalsh | Libvirt Dynamic Labeling. | Nov 17 08:00 |
dwalsh | This slide is probably the most difficult to understand. | Nov 17 08:01 |
dwalsh | In RHEL5 xen policy we are basically protecting the host from the virtual machines. | Nov 17 08:01 |
dwalsh | We wrote rules that says xend_t can read/write xen_image_t but it can not read user_home_t. | Nov 17 08:02 |
dwalsh | So a compromised xen could not read the hosts home directories. | Nov 17 08:02 |
dwalsh | But Since it can r/w xen_image_t it could r/w another xen_image_t | Nov 17 08:02 |
dwalsh | So Pepsi virtual machine can read the coke virtual image and steal it secrets. | Nov 17 08:03 |
dwalsh | Not good. | Nov 17 08:03 |
dwalsh | We wanted to define a policy where the processes would run with the exact same privs | Nov 17 08:03 |
dwalsh | but not be able to interact with each other. | Nov 17 08:03 |
dwalsh | So we needed almost the same labels with a slight variation. | Nov 17 08:04 |
dwalsh | ENTER MCS | Nov 17 08:04 |
dwalsh | MCS stands for Multi-Category-Security | Nov 17 08:04 |
dwalsh | It is the fourth field of the SELinux label | Nov 17 08:04 |
dwalsh | User:Role:Type:MCS (Or MLS) | Nov 17 08:04 |
dwalsh | The fourth field had been added to support MLS - Multi-Level-Security for RHEL5 | Nov 17 08:05 |
dwalsh | This is the stuff that handles labels like TopSecret and Unclassified. | Nov 17 08:05 |
dwalsh | But we did not want MLS on Targeted policy. | Nov 17 08:05 |
dwalsh | We still wanted to use the fourth field for something | Nov 17 08:06 |
dwalsh | But while people have experimented with using it for things like PatientRecord or CompanyConfidential | Nov 17 08:06 |
dwalsh | It never got on. | Nov 17 08:06 |
dwalsh | And there were some problems with its design. | Nov 17 08:06 |
dwalsh | Most SELinux developers believe you should use the Type field for this kind of labeling. | Nov 17 08:07 |
<--mintos has quit ("Leaving") | Nov 17 08:07 | |
dwalsh | Anyways we had the capability of using the fourth field, for isolation. | Nov 17 08:07 |
dwalsh | We decided to generate a random mcs field like s0:c134, c514 | Nov 17 08:07 |
dwalsh | And use this to label the virtual machine | Nov 17 08:08 |
dwalsh | Virtual machines get random labels like | Nov 17 08:08 |
delhage | why 2 categories like that? | Nov 17 08:08 |
dwalsh | system_u:system_r:svirt_t:s0:c134,c514 | Nov 17 08:08 |
dgrift | else you have only room for 1024 unique machines | Nov 17 08:08 |
delhage | makes sense, thanks | Nov 17 08:09 |
dwalsh | 2 categories gives us 1024*1024 combinations | Nov 17 08:09 |
*delhage nods | Nov 17 08:09 | |
-->nmudgal (i=d2d46c84@gateway/web/freenode/x-ozgfpxbnzcqgfoxn) has joined #fedora-classroom | Nov 17 08:09 | |
dwalsh | But really we need to devide by 2 and we don't allow them to be the same | Nov 17 08:09 |
dwalsh | So we can run 1024*1024/2 - 1024 | Nov 17 08:10 |
dwalsh | Virtual machines | Nov 17 08:10 |
-->mintos (n=mvaliyav@nat/redhat/x-okcapllstcrpsgea) has joined #fedora-classroom | Nov 17 08:10 | |
dwalsh | And these are currently unigue to the host | Nov 17 08:10 |
dwalsh | So until we approach 500,000 | Nov 17 08:10 |
dwalsh | simultanious vms | Nov 17 08:10 |
dwalsh | 2 is enough | Nov 17 08:10 |
dwalsh | But we can up it to 3, 4... | Nov 17 08:10 |
dwalsh | So in dynamic mode | Nov 17 08:11 |
dwalsh | libvirt generates a semi random MCS label and makes sure it is unique | Nov 17 08:11 |
dwalsh | Then it labels the virtual machine | Nov 17 08:11 |
dwalsh | using this label | Nov 17 08:11 |
dwalsh | system_u:object_r:svirt_image_t:MCS1 | Nov 17 08:12 |
dwalsh | And starts the virtual machine as | Nov 17 08:12 |
dwalsh | system_u:object_r:svirt_t:MCS1 | Nov 17 08:12 |
dwalsh | Which allows the virtual machine to read its image file | Nov 17 08:12 |
dwalsh | When it starts a second virtual machine | Nov 17 08:13 |
dwalsh | it picks another MCS label | Nov 17 08:13 |
dwalsh | MCS2 | Nov 17 08:13 |
dwalsh | using this label | Nov 17 08:13 |
dwalsh | system_u:object_r:svirt_t:MCS2 | Nov 17 08:13 |
dwalsh | system_u:object_r:svirt_image_t:MCS2 | Nov 17 08:13 |
<--mj0vy has quit ("Leaving.") | Nov 17 08:13 | |
dwalsh | Now svirt_t:MCS1 is prevented from R/W svirt_image_t:MCS2 | Nov 17 08:14 |
dwalsh | So Pepsi is prevented from attacking Coke. | Nov 17 08:14 |
dwalsh | libvirt supports 4 labels | Nov 17 08:14 |
dwalsh | svirt_image_t:MCS for Unshared content | Nov 17 08:14 |
dwalsh | Shared Read/Only content like cdroms | Nov 17 08:15 |
dwalsh | virt_content:s0 | Nov 17 08:15 |
dwalsh | Shared R/W content | Nov 17 08:15 |
dwalsh | svirt_image_t:s0 | Nov 17 08:15 |
dwalsh | And a label virt_image_t:s0 which no virtual machines can read or write | Nov 17 08:15 |
dwalsh | This is the label all virtual content gets when the virtual machine is not running. | Nov 17 08:16 |
dgrift | hoe would you apply a different label? virsh-edit? | Nov 17 08:16 |
dwalsh | Yes coming to that | Nov 17 08:16 |
dgrift | ok | Nov 17 08:16 |
dwalsh | next slide | Nov 17 08:16 |
dwalsh | This slide show in picture that how this works | Nov 17 08:17 |
delhage | is the slide wrong or is R/W shared content svirt_t:s0? | Nov 17 08:17 |
dwalsh | The slide is wrong | Nov 17 08:17 |
delhage | ok | Nov 17 08:17 |
dwalsh | svirt_t:s0 is a process label. | Nov 17 08:17 |
dwalsh | I mean to fix this. | Nov 17 08:17 |
dwalsh | In this slide the virtual machine svirt_t:MCS1 is shown being compromised | Nov 17 08:18 |
dwalsh | The Hypervisor has a compromise | Nov 17 08:18 |
dwalsh | and the hacker is breaking out and attempting to attack the HOST. | Nov 17 08:19 |
dwalsh | But SELinux steps in and blocks the attack | Nov 17 08:19 |
dwalsh | since svirt_t:MCS is not allowed to read fixed_disk_device_t or user_home_t | Nov 17 08:19 |
dwalsh | Also if svirt_t:MCS1 attempts to attack svirt_t:MCS2 or svirt_image_t:MCS2 it will be blocked by SELinux | Nov 17 08:20 |
dwalsh | One think I have demoed is to start an virtual machine using libvirt and then go in with chcon -l and change the MCS label. | Nov 17 08:20 |
dwalsh | Now watch the virtual machine slowly blow up. | Nov 17 08:21 |
dwalsh | Your log files will also fill up with AVC messages. | Nov 17 08:21 |
dwalsh | next slide | Nov 17 08:21 |
dwalsh | We have talked about dynamic labeling but what about people wanting to use their own policy | Nov 17 08:22 |
dwalsh | or use MLS? | Nov 17 08:22 |
dwalsh | MLS does not like the idea of content dynamically changing its security level. | Nov 17 08:22 |
dwalsh | MLS works real hard to prevent this. | Nov 17 08:23 |
-->jaswinder (n=jaswinde@59.180.75.149) has joined #fedora-classroom | Nov 17 08:23 | |
dwalsh | We wanted this technology to be used by MLS type people so we added static labeling. | Nov 17 08:23 |
dwalsh | In a static label environment the administrator is required to label the content | Nov 17 08:24 |
dwalsh | and libvirt will NOT change it. | Nov 17 08:24 |
dwalsh | If I have a virtual machine that needs to run at TopSecret I label the image as TopSecret and then tell libvirt to run the process at TopSecret | Nov 17 08:25 |
dwalsh | This does not give you the isolation that you get using Dynamic. | Nov 17 08:25 |
dwalsh | Meaning a compromised svirt_t:TopSecret can attack other svirt_t:TopSecret processes. | Nov 17 08:25 |
dwalsh | But in MLS this is ok. (Theoretically) | Nov 17 08:26 |
dwalsh | You can also run Static labels and Dynamic Labels at the same time. | Nov 17 08:26 |
dwalsh | So you could set up one virtual machine to always run with one hard coded label and have the rest of the virtual machines running dynamically. | Nov 17 08:27 |
dwalsh | Not sure if this is a valid use case but it will work. | Nov 17 08:27 |
dwalsh | libvirt would not guarantee that the dynamic label would not match a static label though | Nov 17 08:27 |
dwalsh | So your static label better have a different type or more then two fields in the MCS label. | Nov 17 08:28 |
dwalsh | Next Slide | Nov 17 08:28 |
Josh_Borke | is that a planned enhancement? | Nov 17 08:28 |
dwalsh | Don't know. | Nov 17 08:28 |
dwalsh | I need to see if this is a valid use case | Nov 17 08:28 |
dgrift | what if you want it? | Nov 17 08:28 |
dwalsh | This slide show Virt Manager | Nov 17 08:28 |
dgrift | you can expect to svirt to know | Nov 17 08:29 |
dgrift | cant* sorry | Nov 17 08:29 |
dwalsh | We are not analyzing the list of static virtual machines to see if the MCS portion of the label overlaps the MCS range, but I guess theoretically this is possible. | Nov 17 08:29 |
dwalsh | A lot of work and not likely much value. | Nov 17 08:30 |
dwalsh | Anyways this slide show the gui that you could specify a static label | Nov 17 08:30 |
dwalsh | It also shows you could pick different security mechanisms then SELinux in svirt. | Nov 17 08:31 |
dwalsh | Like None. | Nov 17 08:31 |
dwalsh | Which will disable the setting of the labels | Nov 17 08:31 |
dwalsh | And I think Suse has hacked up an AppArmour way of doing something similar | Nov 17 08:31 |
dwalsh | NextSlide | Nov 17 08:32 |
dwalsh | This slide shows the static labeled virtual machines running in MLS mode. | Nov 17 08:32 |
dwalsh | Realize that while you can run MLS environment using this mechanism. Currently there is no Common Criteria to cover this use case. | Nov 17 08:32 |
dwalsh | The government will probably require a Virtualization Common Criteria before it would accept it. | Nov 17 08:33 |
dwalsh | This is something Red Hat and its partners are investigating. | Nov 17 08:33 |
dwalsh | Next Slide | Nov 17 08:34 |
dwalsh | One suggested Future Enhancement is to allow users to specify alternative types | Nov 17 08:34 |
dwalsh | For example svirt_web_t | Nov 17 08:34 |
dwalsh | Which would allow the virtual machine to use only the http ports. | Nov 17 08:34 |
dwalsh | You can imaging you could run a windows virtual machine on a RHEL5 box and even if the virtual machine became compromised | Nov 17 08:35 |
dwalsh | SELinux could prevent it becoming a spam bot. | Nov 17 08:35 |
<--npatil has quit (Remote closed the connection) | Nov 17 08:35 | |
dgrift | and also provide the protection that the mcs method brings? | Nov 17 08:35 |
dwalsh | Yes it would still be dynamic labeling | Nov 17 08:36 |
dgrift | then why not skip mcs because te seems more flexible | Nov 17 08:36 |
dwalsh | But I believe iptables would give you better confinement and more fine grained control. | Nov 17 08:36 |
dwalsh | Although the SELinux work is easier. | Nov 17 08:36 |
dwalsh | mcs gives you isolation between virtual machines | Nov 17 08:37 |
dwalsh | If you run two svirt_web_t you want them isolated | Nov 17 08:37 |
dgrift | well doesnt the te method do this as well | Nov 17 08:37 |
dgrift | true | Nov 17 08:37 |
dgrift | but you can do web1 web2 | Nov 17 08:37 |
dwalsh | Yes if you want to write policy you could write multiple domains | Nov 17 08:38 |
dwalsh | But when the domains need the exact same access | Nov 17 08:38 |
dwalsh | But isolated you end up with an explosion of policy | Nov 17 08:38 |
dgrift | attributes | Nov 17 08:38 |
dgrift | true | Nov 17 08:38 |
dwalsh | That is the end of the svirt | Nov 17 08:38 |
dgrift | but also more optional | Nov 17 08:38 |
dgrift | thanks | Nov 17 08:38 |
dwalsh | Talk questions | Nov 17 08:38 |
dwalsh | svirt is in F11 and F12 | Nov 17 08:39 |
dwalsh | It is potentially going to be back ported to RHEL5.6 | Nov 17 08:39 |
dwalsh | It will be in RHEL6 | Nov 17 08:40 |
-->kashyapc (n=Kashyap@115.184.86.114) has joined #fedora-classroom | Nov 17 08:40 | |
dwalsh | It is in the upstream project so others can replace the SELinux svirt module with other security mechanisms. | Nov 17 08:40 |
dwalsh | Oh one last point. | Nov 17 08:40 |
dwalsh | When you are deciding on a Virtualization technology. | Nov 17 08:40 |
dwalsh | Always ask the vendo? | Nov 17 08:41 |
dwalsh | What mechanism do you use to mitigate a Hypvervisor Vulnerabiltiy | Nov 17 08:41 |
dwalsh | If they tell you their code is too good, Laugh at them | Nov 17 08:41 |
dwalsh | All Code is broken. And Crackers will find a way. | Nov 17 08:42 |
dwalsh | Thanks for listening. If anyone is still out there... | Nov 17 08:42 |
rprice | dwalsh: Thanks ;) | Nov 17 08:42 |
dgrift | thanks again | Nov 17 08:42 |
inode0 | yes, thanks a lot for doing this dwalsh | Nov 17 08:42 |
dwalsh | Or I guess it should be thanks for reading. | Nov 17 08:42 |
delhage | thanks | Nov 17 08:42 |
*inode0 suspects some of us could hear you | Nov 17 08:43 | |
Josh_Borke | dwalsh: thanks | Nov 17 08:45 |
dwalsh | Does this get archived somewhere? | Nov 17 08:45 |
zer0c00l | dwalsh: thanks :) | Nov 17 08:45 |
inode0 | when backported to RHEL5 will sVirt be a KVM only enhancement or will it apply to Xen too? | Nov 17 08:46 |
dgrift | usually | Nov 17 08:46 |
zer0c00l | dwalsh: yeah | Nov 17 08:46 |
dgrift | but i dunno if it currently logged | Nov 17 08:46 |
delhage | I can't see how it could be applied to xen? | Nov 17 08:46 |
dwalsh | kvm only, although I think you can run xen images within qemu out of libvirt | Nov 17 08:46 |
delhage | ok | Nov 17 08:46 |
dgrift | The_4_key_causes_of_SELinux_errors_(20090503_Classroom) | Nov 17 08:47 |
dwalsh | I might do a talk on sandboxing next month | Nov 17 08:47 |
dwalsh | My fingers are exhausted. :^) | Nov 17 08:47 |
inode0 | thanks again | Nov 17 08:48 |
Josh_Borke | svirt is pretty exciting, especially that it is almost invisible | Nov 17 08:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!