| Recent Articles |
The Missing Manual: Mac OSX Leopard Edition
Unlike Mac OS X Leopard Pocket Guide, this is the book you really should buy if you are running Leopard. At almost 900 pages, this is wonderfully complete...
Improve QuickLook In Leopard
Leopard's new "Quicklook" is a nice tool, but for stubborn old command line types like me, it has some limitations: it won't show me plain text files unless they have...
41 Bugs Attended To In Latest Round Of Leopard...
David Utter has posted a story at SecurityProNews regarding the ever-important topic of security fixes for Mac OS X Leopard and the Safari web browser.
I can't...
On Leopard Compatibility
I know a lot of people rushed to installed Leopard (Mac OS X 10.5) last night and my friends found it very odd that I was not one of those early adopters.
|
|
01.17.08
Mac Sandbox Wrapper
 By
A.P. Lawrence
Mac OS X Leopard includes a new command line tool called "sandbox-exec". What it does is provide a "sandbox" - a restricted environment.
You can use this to provide more safety when testing unknown software (such as that whiz-bang thingy you just downloaded) or to provide additional security for our ordinary applications and daemons..
Let's try something very simple. First we need to create a sandbox profile. There are pre-made profiles in /usr/share/sandbox, but we'll make our own here. I'll call it "my.sb":
The "deny network*" in our profile stopped us from using the network. There are other restrictions we can enforce in our sandbox: we can prohibit file system writes, prohibit writes except to /tmp or other specific places, allow only certain libraries to be read , and much more. The best place to get an idea of what's possible is to look at the /usr/share/sandbox files: strangely, they aren't XML as most of Mac OS X is now, but they are easy enough to understand in spite of being undocumented.
If we had a suspicious binary, we could run it within a sandbox that locked it down from doing anything potentially harmful. We could also run processes that we fear might be subverted - a web server or ssh server, for example. Any sub-process started by a sandboxed process will be just as restricted, so this would let us very specifically allow only what our process needs to do its work. If it were hacked, the resulting process would be prevented from doing anything more. In combination with our normal security measures (permissions, acl's and so on), this could provide a very large degree of security.
A comment in one of the /usr/share/sandbox files might indicate that a different name for this was contemplated:
Use "debug deny" to log only operations that are denied by seatbelt
Seatbelt? OK, a seatbelt restrains you and keeps you from hurting yourself..
There is, of course, a system call for the same purpose - sandbox_init() - and a man page. There's also a "sandbox" man page that is supposedly an overview of this facilty, but neither of them are very helpful. A little experimentation would probably tease out their secrets.
Comments
*Originally published at APLawrence.com
About the Author:
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
|
