Example 1
This example uses sandbox_init() with one of the predefined policies Apple provides. In this case, we’re going to use the kSBXProfileNoWrite policy, which prevents the process from writing any files to disk. The example program is:

#include <sandbox.h>
#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>

int main(int argc, char *argv[])
{
	int ret, fd;
	char **errbuf;
	char buf[50], buf2[] = "blah blah\n";

	ret = sandbox_init(kSBXProfileNoWrite, SANDBOX_NAMED, errbuf);
	if (ret != 0) {
		printf("Error initializing sandbox\n");
		return 1;
	}
	fd = open("temp", O_RDONLY);
	if (fd < 0)
		perror("Error reading temp");
	else {
		read(fd, buf, 50);
		close(fd);
	}
	fd = open("temp", O_WRONLY);
	if (fd < 0)
		perror("Error writing temp");
	else {
		write(fd, buf2, strlen(buf));
		close(fd);
	}
	return ret;
}

This code simply initializes a sandbox with the chosen profile, then attempts to open a temp file for reading, then again for writing. Running this yields the following result:

chadsbook:leopard chad$ ./test1
Error writing temp: Operation not permitted

As expected, the test program can read the file, but not write to it. Looking in /var/log/system.log shows no messages, so apparently the kSBXProfileNoWrite policy does not log denials.

Example 2
This example uses the sandbox-exec command-line utility to place a test program in a sandbox that we create. Note that this is clearly marked as a private API that is subject to change in the header files, so try this with care. The test program is the same as the above without the sandbox_init() part (available here if you don’t trust me). The policy, written in the seatbelt Scheme-like language is as follows:

;;
;; Test seatbelt sandbox policy
;;
(version 1)

;; Turn on debugging for denials
(debug deny)

;; Import basic rules from bsd policy
(import "/usr/share/sandbox/bsd.sb")

;; Allow all process perms
(allow process*)

;; Allow reading a dylib that isn't part of bsd.sb for some reason
(allow file-read-data
  (regex "^/private/var/db/dyld/dyld_shared_cache_i386$"))

;; Allow reading sysctls
(allow sysctl-read)

;; Allow reading test data, but not writing
(allow file-read-data
  (regex "^/Users/chad/Tresys/svn/leopard.*"))

This policy has comments explaining what it does. Note that I have a (debug deny) message at the beginning, telling the kernel to log denials. This allowed me to look in /var/log/system.log to see what was being denied and allow it if necessary. That’s how I can up with several of these allow rules. Running the test program with this policy yields:

chadsbook:leopard chad$ sandbox-exec -f test2.sb ./test2
Error writing temp: Permission denied

Again, the result we expect. This time, though, we’ve got the kernel logging denials. So, looking in /var/log/system.log yields:

Nov  8 16:09:50 chadsbook kernel[0]: test2 4511 FS_WRITE_DATA SBF /Users/chad/Tresys/svn/leopard/temp 13 (seatbelt)

Here we see that indeed seatbelt blocked our test program from writing to our file, confirming what we’ve seen.

At some point, I’ll try to talk about useful things you can do with Apple’s sandbox mechanism, as well as potentially compare/contrast it with SELinux. For now, though, just know that Apple’s pursuing stronger security mechanisms as well. That said, the list of applications actually sandboxed by default on Leopard is very small, so don’t think you’re getting a lot of protection from this today. This is more of an indicator of the good things to come as well as a mechanism you can use to protect your apps today.

First, let me say that much of this is gleaned or inferred from looking at a running system and the XNU source code. There is a bit of documentation on this feature, but it is limited. In addition, much of what is possible is labeled as “Apple System Private Interface and are subject to change at any time and without notice” so I wouldn’t plan my corporate infrastructure around using it just yet.

Apple has implemented the sandbox mechanism by utilizing the MAC Framework developed by the TrustedBSD project. This is a kernel framework similar to the Linux Security Module (LSM) framework that SELinux uses to hook into the Linux kernel. Note that TrustedBSD’s SEDarwin project also ported the SELinux policy decision engine to Darwin, but Apple decided to implement their own policy decision engine instead of using SEDarwin’s. That engine is called seatbelt, and it’s a kernel extension (found in /System/Library/Extensions/seatbelt.kext).

Seatbelt does not appear to be released as source, so I can only surmise how it works from attempts to use it. It appears to provide pathname-based access control (not my favorite). Additionally, processes are not confined by seatbelt by default. Instead, a process must opt-in (by calling sandbox_init()) to be confined. Once confined, all children are also confined by the same policy, meaning that you can have a wrapper call sandbox_init() and then execute the program you really want to confine. In fact, it looks like Apple thought this might be useful as they included a command-line utility called sandbox-exec which appears to do just that.

A process selects which policy will confine it at sandbox_init() time. There are two ways to do this. The first way, which is the only one officially supported by Apple according to the documentation, is to choose a policy that is statically compiled into the kernel. Apple documented five of these, each with a high-level goal. These goals include no internet, no networking, no file writing, no file writing except temporary files, and pure computation.

The second way of selecting a policy, which is clearly marked as a private API that is subject to change, is to provide a pathname to a policy file. While there is no documentation of the format of the policy file, there are several examples available in /usr/share/sandbox which give clues to what a policy can do. These policies seem to use a Scheme-like syntax and provide abilities to restrict file access (based on pathname), restrict interprocess communication (IPC) such as shared memory, restrict network access, restrict signals, restrict many process-related actions, restrict sysctls, and more.

Stay tuned for some examples of using sandboxes on Leopard.

Some of you may be scratching your head seeing SELinux, Montavista, and embedded all together. Yes, SELinux can be used beyond server systems. Linux is growing incredibly quickly in embedded devices, being used in cell phones, set-top boxes, cameras, televisions, and even hard disks (yeah, that shocked me too). And many of these devices have lots of security issues. Which is why Montavista has announced support for SELinux in their upcoming release. I look forward to buying my first cell phone with SELinux protecting my personal data. Maybe if Apple had Mandatory Access Controls in their embedded OS they could be more comfortable with allowing 3rd party application that wouldn’t break the rest of the system.

Goal
Prevent an attacker from accessing customer records on a web site.

Approach
Solving confidentiality problems generally involves two activities. The first entails ensuring that whatever has to access the confidential data is not exploitable. This is a tall order, but is not impossible. The best strategy to take here is to make that program that has to access the confidential data as small and analyzable as possible. You can take great care in writing it and in analyzing it to ensure its correctness. So, I need to make my “guard” application that grants access to the data as small as possible. It should only contain code to do what it needs to do to authenticate the user and give back the data that user is authorized to see.
After ensuring that the application that needs access to the data is solid, the second activity in solving this problem is to ensure that nothing else can access the data. This is where I’ll use SELinux access controls. I’ll build an SELinux domain for the authentication application to run in as well as a type for the confidential records on disk. I’ll then allow only the authenitication application to access the confidential records. By doing this, I can prevent other things on the website (as well as the rest of the system) from accessing the records. An attacker may be able to compromise another part of my website, but he will not be able to get to my confidential records.¹

Details
Example system

• Fedora 7
• Targeted SELinux policy²
• Apache

I wrote a quick python script to use as my example application. It simply receives authentication data and displays the contents of the confidential records if the authentication is successful. This is admittedly an overly simple illustration, but those are often the best examples. I also wrote another simple script for demonstration purposes to serve as a vulnerable application also hosted on my website. I’ll have Apache execute these scripts as a cgi. Note that this will not work if I was using mod_python, as mod_python executes the script with the apache process. Consequently I’d be forced to try to confine apache itself, and I clearly can’t place all these restrictions on apache.

I created my SELinux policy with SLIDE, which filled in much of the details for me through a basic wizard. This wizard created a type for my application (records_t) and its corresponding executable (records_exec_t) and granted some basic accesses that almost everything needs (like access to shared libraries and locale). I then really only needed to add four things to make the application work.

1. type record_data_t;
files_type(record_data_t)

   This creates a type for the confidential records, which separates it from the other files on the website so we can protect it.

2. corecmd_exec_bin(records_t)

   This simply gives the authentication application the ability to execute common binaries on the system (mostly in /bin and /usr/bin). In particular, this is necessary to execute python.

3. allow records_t record_data_t:file read_file_perms;

   This allows the application to read the confidential records. Note that the important part here is that I have not granted anything else the ability to read these records. Also, note that this is an allow rule rather than an interface call. Interface calls are used for interfacing with other modules within the policy. Here we are not interfacing with other policy modules, but are rather just allowing access internal to our policy module.

4. apache_cgi_domain(records_t, records_exec_t)2

   This does a couple of things. First, it ensures that when Apache executes our web app, the web app runs in the proper domain (records_t). Secondly, it allows our web app to talk to Apache.

The full source code of the policy and the test applications are available here.

Results

1. This is the authentication applicaiton granting access to the records after I enter proper credentials. This shows how things are supposed to work, as well as that our SELinux policy is letting the proper workflow occur without problems.

2. SELinux disabled	SELinux enabled

   This is a view of utilizing the vulnerable application (hacked.py) to get to the customer records. This application had no right to access this data, but without access controls stopping it, it can be used to bypass authentication. On the contrary, with SELinux enabled this program is denied access to the records.

¹ Note that this example assumes that the confidential data is stored in a file that will be directly read by the web application. Another common scenario is that the confidential data is instead stored in a database which the web application accesses by talking to a database server. The operating system has no visibility into the database server, so SELinux can only control which web applications can talk to the database server, not what data the database server can give them. Thankfully, database server developers have thought of this already. In fact, there is a project to create a security enhanced postgresql server which cooperates with SELinux to enforce very powerful fine-grained mandatory access control over databases. With this, it’s possible to enforce access control over the individual entries in the database. Other databases, such as mysql, at least have a coarse-grained discretionary access control usually implemented as authentication credentials required for accessing a database. If this is a username and password stored in the web application’s config file, then I can use SELinux to protect that config file in the same way that I used SELinux to protect the records themselves above. So, it’s at least possible to indirectly control who can access the records stored in the database.
² This policy is built on the upstream Fedora 7 targeted SELinux policy with one exception. The apache_cgi_domain() interface does not exist there yet. When I started working on this blog entry, this interface did not exist. So, I wrote it and upstreamed it to the Reference Policy project (which serves as upstream for most distros including Fedora). As of today, this interface hasn’t made it into Fedora yet, but it shouldn’t be long. For the above example, I backported this interface into the current Fedora policy.

Goal
Prevent an attacker from uploading and executing malicious software through vulnerabilities in the web application.

Approach
I’ll use SELinux to confine the web application. This will involve building an SELinux domain for the web application to run in that cannot execute anything it writes to disk or access the network directly. The strictest policy I could write would not allow the domain to write anything to disk at all, but that is often not feasible for web apps, as part of their function often involves receiving uploads. By eliminating the ability to execute something that has been uploaded, I can significantly reduce the attackers ability to utilize previously generated malicious code such as a root-kit. However, the attacker may still be able to send malicious code by taking over the web app process itself. While I cannot prevent this without having a bullet-proof web app, I can limit what the attacker can do by preventing all direct access to the network. This prevents the attacker from using a compromised web app process as a bot. Additionally, I’ll limit the access that the web app has to only what is necessary for it to function in order to prevent the compromised app from scouring the system for information or further vulnerabilities.

Details
Example system

• Fedora 7
• Targeted SELinux policy¹
• Apache

I wrote a quick python script to use as my example application. It basically just receives uploads and stores them on disk. It also includes a couple of attacks for testing if my policy is working. I’ll have Apache execute this script as a cgi. Note that this will not work if I was using mod_python, as mod_python executes the script with the apache process. Consequently I’d be forced to try to confine apache itself, and I clearly can’t place all these restrictions on apache.

I created my SELinux policy with SLIDE, which filled in much of the details for me through a basic wizard. This wizard created a type for my application (bb_t) and its corresponding executable (bb_exec_t) and granted some basic accesses that almost everything needs (like access to shared libraries and locale). I then really only needed to add four things to make the application work.

1. type bb_uploads_t;
files_type(bb_uploads_t)

   This creates a type for the uploads directory and all the files that are uploaded. This type cannot be executed by the web app or apache.

2. corecmd_exec_bin(bb_t)

   This simply gives the web app the ability to execute common binaries on the system (mostly in /bin and /usr/bin). In particular, this is necessary to execute python.

3. manage_files_pattern(bb_t, bb_uploads_t, bb_uploads_t)

   This allows the web app the ability to create, read, write, delete, etc. (but not execute) files and directories in the uploads directory.

4. apache_cgi_domain(bb_t, bb_exec_t)1

   This does a couple of things. First, it ensures that when Apache executes our web app, the web app runs in the proper domain (bb_t). Secondly, it allows our web app to talk to Apache.

The full source code of the policy and the test web app are available here.

Results
My example python script includes two exploits. The first allows an attacker to execute something that’s been uploaded. The second assumes that the attacker has taken over the web app itself, and attempts to bind to a network port to await instructions from the attacker. Below, I execute both attacks twice - once with SELinux disabled and once with SELinux enabled.

1. SELinux disabled	SELinux enabled

   To test executing uploaded files, I upload a script that simply prints “You have been hacked!” Note that the SELinux policy prevents this from being executed.

2. SELinux disabled	SELinux enabled

   To test accessing the network, my web app attempts to bind to tcp port 1337 and responds on that port to anything that connects to it. Note again that SELinux policy prevents this access, as well as any other network access it may attempt.

¹ This policy is built on the upstream Fedora 7 targeted SELinux policy with one exception. The apache_cgi_domain() interface does not exist there yet. When I started working on this blog entry, this interface did not exist. So, I wrote it and upstreamed it to the Reference Policy project (which serves as upstream for most distros including Fedora). As of today, this interface hasn’t made it into Fedora yet, but it shouldn’t be long. For the above example, I backported this interface into the current Fedora policy.

This blog will follow a pattern of choosing a security problem and looking at how to solve that problem. As often as possible, this will come in the form of technical examples including code and policy snippets. This blog will often utilize SELinux in some way to solve those problems. There are 2 reasons for this. First, I’m heavily involved in SELinux in my day job at Tresys, so the problems I see are frequently addressable by SELinux. Second, SELinux is a very flexible security framework, so it actually does address a very large number of security problems. That said, I’m going do my best to focus on solving the problem and utilizing appropriate technology to do it.

So, sit back and enjoy. Hopefully you’ll find solutions to some of the security problems you’re facing today. If not, feel free to let me know what those problems are so I can try to focus on them in future posts.