Security vs Usability
I was down in Washington last week and had some meetings with people from Sun Microsystems. I asked them, "If I ran Apache on OpenSolaris, would it run by default within its own zone?" He told me no. I thought, well what is the point? If I am not providing security for the masses, I don't feel I am doing my job.
As "open source security engineers," we try to add new features to the operating system to make the system more secure for everyone. But if we add features that are turned off by default, then are we really helping?
I am looking for new features that I can add to Fedora to make the system more secure for everyone. That is the reason Red Hat Enterprise Linux and Fedora have SELinux enabled by default. This increased use has allowed SELinux to develop and improve greatly over the years.
But we are always having to make sacrifices for usability. For example, Fedora 5 and all releases since have had executable memory checks. These checks watch for applications that allocate memory that is both writeable and executable. Buffer overflow attacks rely on being able to write code to memory and then execute it, and these checks prevent that. While these checks are on for almost all confined domains, they are turned off by default for the logged in user. We have not been able to turn these checks on because of the amount of badly written applications that SELinux causes to blow up. As of Fedora 10 we feel we have fixed enough applications to leave the checks on by default, potentially eliminating a whole range of vulnerabilities.
Xen problems:
While we were developing policy for Fedora 6/RHEL5, we wanted to write a tight policy for Xen. The problem is xend is a huge application that requires lots of privileges to run, and any confinement we added was met with anger by the Xen community. One of the changes we wanted to make was to force the labeling of image files on disk or physical storage as xen_image_t. Then xend could be allowed to read and write these disk images but not other disk images. The Xen developers thought it would be too much of an inconvenience to force the users to have to maintain these labels, so I relented and allowed xend to read and write disks labeled as generic fixed disk. I knew this made the control of Xen via SELinux pretty useless, but "Xen had to just work".
Well...
Adventures with a certain Xen vulnerability
was just published which contains a Xen vulnerability which allows a process in a virtual machine to attack the host machine, and SELinux is pretty much a speed bump in his way.
3.4
What actions are available for an uid 0 process running in thesystem u:system r:xend t:s0 context? It turns out that default SELinux policy allows very few. For instance, we cannot write to system configuration files, nor load kernel modules.
However, qemu-dm processes also implement virtual block devices for HVM guests, and these devices can be backed by raw disk partitions. In order to make it possible, the default SELinux policy grants xend t domain the read-write access to all disk partitions. The relevant lines in the SELinux reference policy (from the default selinux-policy-3.0.8-44.fc8.src.rpm) are:
storage_raw_read_fixed_disk(xend_t)
storage_raw_write_fixed_disk(xend_t)
Particularly, qemu-dm (so, the shell executed from it as well) can write to the blocks on the root filesystem.
Through the use of fixed disk the attacker is able to trick the host operating system into loading kernel modules that can take over the machine. If we had forced the users to label the physical disk partitions, this vulnerability would not have been exploitable.
Lesson learned. When it comes to virtualization going forward, I plan on forcing the user to apply the correct labeling. KVM/QEMU have nice process separation and make confinement easier. virt_manager and libvirt are being built with SELinux understanding in them. virt_manager will setup the labeling correctly when virtual images are installed and libvirt will make sure they run in the correct domain when they are launched.
In the future we want to protect not only the host machine from the virtual machines, but the virtual machines from each other. Watch for information on sVirt in the future.
In conclusion, as we move towards more widespread use of virtualization, we should avoid making compromises in security for the sake of usability, but work toward making security usable.
As "open source security engineers," we try to add new features to the operating system to make the system more secure for everyone. But if we add features that are turned off by default, then are we really helping?
I am looking for new features that I can add to Fedora to make the system more secure for everyone. That is the reason Red Hat Enterprise Linux and Fedora have SELinux enabled by default. This increased use has allowed SELinux to develop and improve greatly over the years.
But we are always having to make sacrifices for usability. For example, Fedora 5 and all releases since have had executable memory checks. These checks watch for applications that allocate memory that is both writeable and executable. Buffer overflow attacks rely on being able to write code to memory and then execute it, and these checks prevent that. While these checks are on for almost all confined domains, they are turned off by default for the logged in user. We have not been able to turn these checks on because of the amount of badly written applications that SELinux causes to blow up. As of Fedora 10 we feel we have fixed enough applications to leave the checks on by default, potentially eliminating a whole range of vulnerabilities.
Xen problems:
While we were developing policy for Fedora 6/RHEL5, we wanted to write a tight policy for Xen. The problem is xend is a huge application that requires lots of privileges to run, and any confinement we added was met with anger by the Xen community. One of the changes we wanted to make was to force the labeling of image files on disk or physical storage as xen_image_t. Then xend could be allowed to read and write these disk images but not other disk images. The Xen developers thought it would be too much of an inconvenience to force the users to have to maintain these labels, so I relented and allowed xend to read and write disks labeled as generic fixed disk. I knew this made the control of Xen via SELinux pretty useless, but "Xen had to just work".
Well...
Adventures with a certain Xen vulnerability
was just published which contains a Xen vulnerability which allows a process in a virtual machine to attack the host machine, and SELinux is pretty much a speed bump in his way.
3.4
What actions are available for an uid 0 process running in thesystem u:system r:xend t:s0 context? It turns out that default SELinux policy allows very few. For instance, we cannot write to system configuration files, nor load kernel modules.
However, qemu-dm processes also implement virtual block devices for HVM guests, and these devices can be backed by raw disk partitions. In order to make it possible, the default SELinux policy grants xend t domain the read-write access to all disk partitions. The relevant lines in the SELinux reference policy (from the default selinux-policy-3.0.8-44.fc8.src.rpm) are:
storage_raw_read_fixed_disk(xend_t)
storage_raw_write_fixed_disk(xend_t)
Particularly, qemu-dm (so, the shell executed from it as well) can write to the blocks on the root filesystem.
Through the use of fixed disk the attacker is able to trick the host operating system into loading kernel modules that can take over the machine. If we had forced the users to label the physical disk partitions, this vulnerability would not have been exploitable.
Lesson learned. When it comes to virtualization going forward, I plan on forcing the user to apply the correct labeling. KVM/QEMU have nice process separation and make confinement easier. virt_manager and libvirt are being built with SELinux understanding in them. virt_manager will setup the labeling correctly when virtual images are installed and libvirt will make sure they run in the correct domain when they are launched.
In the future we want to protect not only the host machine from the virtual machines, but the virtual machines from each other. Watch for information on sVirt in the future.
In conclusion, as we move towards more widespread use of virtualization, we should avoid making compromises in security for the sake of usability, but work toward making security usable.