I was pleased to see that Google Chromium (the open project behind Google Chrome) is utilizing OS X sandboxes as well. This is the first I’ve heard of a third-party application developer utilizing sandboxes. Kudos to Google for pushing the limit when it comes to browser security. You can read more about this on the Chromium blog.
It looks like Apple will be using sandboxes for a bit more than the current couple processes in the future (perhaps Snow Leopard). Looking at the CUPS code (CUPS was purchased by Apple in February of last year), they’ve added support for sandboxes to their development tree, which will theoretically make it into CUPS 1.4. As OS X exploits start to become available in the wild, I hope Snow Leopard confines many more applications (maybe Safari…). It’s nice to see so many major operating systems adding advanced access control features.
Here are a couple of examples of using sandboxes in Leopard. Both examples involve confining a test application that needs to read a file, but should not be able to write that file. I realize that this could be easily implemented with standard Discretionary Access Control (DAC) mechanisms, but this example is solely for the purposes of demonstrating the mechanism. Perhaps later I’ll show off some more useful examples.
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:
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:
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.
Linux isn’t the only operating system with activity in the enhanced access control department. Apple recently released Mac OS X 10.5 Leopard, which includes a new feature called a sandbox (or seatbelt, depending on where you’re looking) as well. I delved into the sandbox mechanisms a bit and wanted to report my findings.
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.
I had the distinct opportunity to speak at the Montavista Vision conference about SELinux in embedded devices. I’d like to say thanks to all who attended my talk. A copy of the slides is available here. Thanks for all the questions. I hope I answered them to your satisfaction.
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.
I’d like to say thanks to all who attended my talk at LinuxWorld. A copy of the slides is available here. I hope you enjoyed it and got a lot out of it. I just posted the second demo in full here, and I’ll try to get the last one up in the near future. If you have further questions, don’t hesitate to drop me an email or post a comment here. Thanks again.
While it is always preferable to keep confidential information such as customer records away from a website, that is often not feasible. This is especially true in ecommerce, but is true in other areas as well. In order to protect this information, most people will employ some sort of authentication application to ensure that people can only access the data for which they are authorized. Despite this, attackers frequently find ways through or more often around this authentication mechanism.
Prevent an attacker from accessing customer records on a web site.
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.1
Continue reading ‘Preventing Disclosure’
Web applications can be a source of very frequent vulnerabilities. These vulnerabilities can stem from bugs in the program itself as well as the libraries and frameworks upon which it depends. These vulnerabilities are often used as the entry-point for an attacker to upload malicious software onto a system. This software can contain root-kits, bots, data collection agents, or other malicious applications.
Prevent an attacker from uploading and executing malicious software through vulnerabilities in the web application.
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. Continue reading ‘Vulnerable web applications’
Welcome to usefulsecurity.com. This blog is dedicated to providing tips, pointers, howtos, and other information on solving real security problems. Too often today security professionals come up with “solutions” that don’t really help users solve their security problems. This stems from many reasons, including not understanding the problem correctly, not understanding the available technologies, and a desire to sell a solution that may not make sense in a particular environment.
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.