Sandboxing with SELinux in FC5
Since in November 2004, Joanna Rutkowska published "Red Pill... or how to detect VMM using (almost) one CPU instruction", tools for detecting when a program is running in a virtual machine have improved a lot. Pioneer or the programs mentioned by Ed Skoudis and Tom Liston are good examples of those tools. Using them (or the concepts behind them) malware authors can check if the program is running in a virtual environment and behave in a unsuspicious way. This concept has been previously demonstrated by us as a small example in RaDa.
But if we can not trust behavioral analysis running a binary in a virtual machine, how can you safely incorporate software from untrusted sources? This may happen very often to you independently of the platform that you use. There are a lot of useful programs that come from untrusted sources, and you just can't spend the time reading its source code (in case it is available).
Don't worry! SELinux comes to your rescue. Among the different approaches to this problem, SELinux is the one that offers real control over the binary and as much isolation as needed for Linux binaries. SELinux takes advantage of the Linux Security Modules (LSM) framework to implement mandatory access control (MAC) in the Linux kernel. It is supported by most major distributions (i.e. all but SuSE that uses AppArmor.)
SELinux enforcement is coded in a kernel module, but the policy used can be changed dynamically allowing to implement different security models. Fedora Core 2 was, as far as I remember, the first distribution that included SELinux and a strict policy file. That policy tried to restrict undesired behavior so much that using it was too complex for normal users. It is still available for later versions of Fedora, but the team that developed the policies decided to simplify the model to be able to achieve their goal: having a system where the user was protected from system applications that were listening on the network. That was the origin of the targeted policy that tries to isolate the programs that are used by malware for remote access, each one running in a different domain, while keeping the rest of the system as if SELinux was not running.
Thus, what we can do is define our own domain for suspicious binary execution. In order to be able to do so, you need the checkpolicy package installed. If you are using yum, which I definitely recommend, the command "yum install checkpolicy" should do. Then, the easiest way is to run the policygentool:
cd /usr/share/selinux/devel/
policygentool mybinary /path/to/mybinary
After some questions about the program, it will create three files (mybinary.{fc,if,te}). The file context, used to label the files, the public interfaces, that define the transitions to and from other domains, and the type enforcement, that contains the rules for this domain. You can edit these text files later. By now just try to compile them using:
make -f Makefile
A policy module file will be created mybinary.pp. That module can be loaded using semodule, and relabel the executable using restorecon:
semodule -i mybinary.pp
restorecon -v /usr/sbin/mybinary
Since the default policy is very restrictive for the binary, SELinux will prevent it from doing much when running. However, this is exactly what you need to debug your policy. Execute the binary and collect avc (Access Vector Cache) messages. In Fedora Core 5, the audit daemon is not installed by default, and the avc messages can be found in /var/log/messages. But if you choose to install and enable the audit daemon, the messages will be in /var/log/audit/audit.log.
audit2allow can then be used to translate the avc messages to allow rules to fix the policy files (mainly the type enforcement). audit2allow -R will attempt to find interfaces that match the allow rule.
Some help to edit your policy:
Enjoy your sandbox!
But if we can not trust behavioral analysis running a binary in a virtual machine, how can you safely incorporate software from untrusted sources? This may happen very often to you independently of the platform that you use. There are a lot of useful programs that come from untrusted sources, and you just can't spend the time reading its source code (in case it is available).
Don't worry! SELinux comes to your rescue. Among the different approaches to this problem, SELinux is the one that offers real control over the binary and as much isolation as needed for Linux binaries. SELinux takes advantage of the Linux Security Modules (LSM) framework to implement mandatory access control (MAC) in the Linux kernel. It is supported by most major distributions (i.e. all but SuSE that uses AppArmor.)
SELinux enforcement is coded in a kernel module, but the policy used can be changed dynamically allowing to implement different security models. Fedora Core 2 was, as far as I remember, the first distribution that included SELinux and a strict policy file. That policy tried to restrict undesired behavior so much that using it was too complex for normal users. It is still available for later versions of Fedora, but the team that developed the policies decided to simplify the model to be able to achieve their goal: having a system where the user was protected from system applications that were listening on the network. That was the origin of the targeted policy that tries to isolate the programs that are used by malware for remote access, each one running in a different domain, while keeping the rest of the system as if SELinux was not running.
Thus, what we can do is define our own domain for suspicious binary execution. In order to be able to do so, you need the checkpolicy package installed. If you are using yum, which I definitely recommend, the command "yum install checkpolicy" should do. Then, the easiest way is to run the policygentool:
cd /usr/share/selinux/devel/
policygentool mybinary /path/to/mybinary
After some questions about the program, it will create three files (mybinary.{fc,if,te}). The file context, used to label the files, the public interfaces, that define the transitions to and from other domains, and the type enforcement, that contains the rules for this domain. You can edit these text files later. By now just try to compile them using:
make -f Makefile
A policy module file will be created mybinary.pp. That module can be loaded using semodule, and relabel the executable using restorecon:
semodule -i mybinary.pp
restorecon -v /usr/sbin/mybinary
Since the default policy is very restrictive for the binary, SELinux will prevent it from doing much when running. However, this is exactly what you need to debug your policy. Execute the binary and collect avc (Access Vector Cache) messages. In Fedora Core 5, the audit daemon is not installed by default, and the avc messages can be found in /var/log/messages. But if you choose to install and enable the audit daemon, the messages will be in /var/log/audit/audit.log.
audit2allow can then be used to translate the avc messages to allow rules to fix the policy files (mainly the type enforcement). audit2allow -R will attempt to find interfaces that match the allow rule.
Some help to edit your policy:
- Use the references:http://www.nsa.gov/selinux/papers/policy2-abs.cfmhttp://www.lurking-grue.org/writingselinuxpolicyHOWTO.html
- Search for interface macros in the /usr/share/selinux/devel/include directory and use them as needed.
- Limiting read access is only based in contexts. When you allow read or write access to a context, all the files in that context are allowed. You can relabel some files, but then be sure that you can easily reinstall the system.
- SELinux works mainly for Linux, but there are some ports of this solutions to FreeBSD and Mac OS X. There are some propietary solutions for Windows, like CA's eTrust Access Control, too.
- There is a performance impact in running SELinux, but you are probably running it anyhow and using a VM isn't a better alternative in terms of performance.
Enjoy your sandbox!
posted by Jorge Ortiz at 3:30 AM
0 Comments:
Post a Comment
<< Home