6: Application Signing and Sandbox in Objective-C

Creator ECC200 in Objective-C 6: Application Signing and Sandbox

control measures could not adequately address the issue. The work around to this problem is to install an alternative sftp service, whether that is a chrooted ssh-based solution, or a different product altogether, such as Rumpus. This isn t always a step in the right direction though. For instance, Rumpus itself was vulnerable to a zero-day exploit that allowed for remote code execution. The rumpus daemon runs as root, so administrators implementing this solution had exposed servers that could be fully compromised remotely. We re big fans of Rumpus and don t mean to call it out specifically. We just feel it s important to acknowledge that no software is immune to exploitation. NOTE: It is important to acknowledge that no software is immune to exploitation. While it is certainly true that properly written software will be much harder to compromise than poorly written software, the general attitude that a security administrator must hold is that all software is vulnerable. Fortunately, with the introduction of sandboxing, we have tools to adequately address these types of problems through the use of sandbox-profiles, whether we re beefing up protections on Apple s solution or implementing a sandbox around a third-party solution. The following profiles, base.sb and shell.sb, were specifically designed to provide reasonably secure sftp/shell services using OS X servers built-in ssh daemon. We accomplish this by limiting available binaries to any user and limiting available utilities to those required for traditional shell functionality. It further provides protection by restricting read access to any directory or file that both fall outside of our specified file system tree and also is not critical for the proper operation of a shell. Writes to /tmp are allowed for general compatibility.

The base.sb profile provides minimal resources needed to establish a remote shell session. It contains two main privilege blocks shell.dependencies and shell.whitelisted-apps. Privilege blocks are to sandbox profiles what functions are to programming and scripting; they allow for the definition of predefined behavior that can be easily referenced from other profiles. To create a privilege block, you define the block by specifying the name and then encapsulating all of your standard sandbox access provisions inside of the (define) block, as shown below:

(define (userProcesses) (allow process-exec (subPath "/Applications") (subPath "/bin") (subPath "/usr/bin") ) )

In this example, we are creating a set of access provisions that allow for the execution of programs found in /Applications, /bin, or /usr/bin. These provisions are defined but

are not applied until the privilege block is referenced in the profile. This is done by enclosing the defined name on it s own line enclosed in parenthesis:

(userProcesses)

This same concept applies if this profile is imported from a different profile. To enable the access provisions provided in this shell (say we named it userProcesses.sb), we would use the following text in our own profile:

(import "userProcesses.sb") (userProcesses)

We note this because base.sb itself only enforces a small number of access provisions, but as mentioned primarily defines two privilege blocks, shell.dependencies and shell.whitelisted-apps that can be utilized by other profiles. The former privilege block includes only resources necessary to the establishment of an interactive shell, the latter includes innocuous support apps, such as man, pagers/editors, compression utilities, and basic file operands. None of the processes established under shell.whitelisted-apps are needed for basic shell access but are rather niceties to have in a shell environment. This profile provides security by limiting available binaries to those installed in /bin, and a select number of applications residing in other system directories. Additionally, it restricts read access, in the traditional POSIX sense, to any directory or file that falls outside of our specified fs trees and is not critical for the proper operation of a shell. Writes to /tmp are allowed for general compatibility. This profile is referenced for use by several of the previously mentioned profiles and can be included in others as a way to define minimal provisions needed for a shell account.

(version 1) (debug deny) (allow default signal sysctl* mach*) ;; our global denies (deny file-write* file-read-data file-read-metadata (regex "^/.*")) (deny file-write* (regex "^/.*")) (deny process* network*) ;; import the bsd profile (import "bsd.sb") (define (shell.dependencies) ;; required processes for remote shell/sftp access (allow process-exec file-read-data file-read-metadata (regex "^/bin/.*") (literal "/usr/bin/which") (literal "/usr/libexec/sshd-keygen-wrapper") (literal "/usr/libexec/sftp-server")) (allow process-fork) ;; our fine-grained reads. (allow file-read-data file-read-metadata (regex "^(/usr) /bin") (regex "^/dev") (literal "/usr/lib/charset.alias") (literal "/private/var/run/utmpx") (literal "/private/etc/csh.cshrc") (regex "^/usr/share/locale") (regex "^/usr/share/terminfo") (regex "^/usr/libexec")