Tiny Deathstars of Foulness

The Enterprise iPhone and iPad Administrator’s Guide is now shipping (and rapidly moving up in Amazon’s rankings)! There have also been a couple of sightings in Border’s. Apress also sent out a press release and an email blast regarding the book in the past week. So, feel free to buy it using the link below! 🙂

December 9th, 2010

Posted In: Articles and Books, iPhone

Tags: , , , , , , , , , , , , , , ,

In all versions of OS X previous to Leopard, access control restrictions were limited to a security model referred to as Discretionary Access Controls (DAC). The most visible form of DAC in OS X is in it’s implementation of the POSIX file-system security model, which establishes identity-based restrictions on an object in the form of a subject’s user or group membership. Similarly Access Control Lists are a form of discretionary control, though they are far more extensible and discrete then the POSIX model. In such models,  newly created objects or processes inherit their access rights based upon those of the creating subject, so that any spawned objects are not granted access rights beyond that of their creating subject. The key idea behind the DAC model is that the security of an object is left to the discretion of the object’s owner; an object’s owner has the ability to assign varying levels of access control to that object within the confines of the DAC implementation. The DAC model has for decades been a staple in the management of both object/process creation and access across all mainstream computer systems due to it’s user-centric nature. However there is a persistent caveat in these implementations;  in all mainstream implementations of such models, there exists a superuser which has the capabilities to completely bypass access restrictions placed on objects. In POSIX-based Operating Systems such as Unix, Linux, or OS X, this superuser exists in the form of the root user. The existence of such a loophole presents a bit of a paradox. On one hand, it introduces several obvious security ramifications by providing capabilities to completely bypass the DAC model all together; any processes which are invoked by the superuser inherit the “god mode” access controls, they have free reign over the entire system. At the same time, the existence of the superuser account becomes a vital tool for the practical administration of data objects and system resources. In a perfect world, this wouldn’t necessarily be a bad thing. Unfortunately that’s not the world we live in, and it is not uncommon to hear about processes being hijacked for ill-will. If the compromised process has been invoked by the superuser, then the entire system has been compromised, including all user data with it.  With 10.5 Leopard, Apple has introduced a new low-level access control model into their OS, based upon the mandatory access control (MAC) model. Conceptually, the MAC system implements restrictions based upon actors, objects, and actions. In such a system, the actor typically assumes the form of a process, thread, or socket. The object can be any type of resource, such as a file, directory, socket, or even a TCP/UDP network port, among others. The action is simply the request of the actor to be applied to the respective object, and varies depending on the type of object involved in the request. Referring back to the file system model; the actor would be a word processor, the object would be a .txt flat file, and the action would be a call to either read to or write to that text file. When the actor requests access to the object, the MAC authorization system evaluates security policies and decides whether the request can proceed, or if it should be prohibited. In a pure MAC model, the object or process ownership is not generally a consideration; individual users do not have the ability to override defined policy.  Leopard enforces the MAC model via a new framework, architected from TrustedBSD’s MAC framework. This framework introduces “sandbox” access control capabilities which allow a developer or user to apply access control policies to a process, restricting privileges to various specified system resources. The restrictions are generally enforced upon acquisition, so any active file descriptors would not be immediately affected by any policy changes, however, any new open() operations would be subject to the new restrictions. In a fashion similar to the DAC model, new processes and forks will inherit the access restrictions of their parent. In Leopard, these restriction policies can be pre-compiled into any given program, or they can be applied to any executable at runtime.  While Leopard’s MAC framework is based off of TrustedBSD’s,  it’s implementation deploys only a subset of control points provided by the TrustedBSD implementation. Noticeably absent are the majority of the Security Policy Modules available for TrustedBSD and FreeBSD implementations, such as Biba, MLS, or NSA’s FLASK/TE (implemented in SEDarwin), though perhaps some day we’ll see some of these ported to Leopard’s MAC framework.  For now, Apple has offered their own Security Policy Module dubbed “Seatbelt”, which is implemented as a KEXT installed at /System/Library/Extensions/seatbelt.kext.  As of 10.5.2, the feature set of Seatbelt seems to be very much in flux. The only documented way to apply these controls in code is via the sandbox_init() function. Utilizing this function in code provides a way for an application programmer to voluntarily restrict access privileges in a running program. sandbox_init() is very limited at this point, providing only 5 pre-defined constants:  • kSBXProfileNoInternet  – disables TCP/IP networking. • kSBXProfileNoNetwork – disables all sockets-based networking • kSBXProfileNoWrite – disables write access to all filesystem objects • kSBXProfileNoWriteExceptTemporary – disables write access to filesystem objects except /var/tmp and `getconf DARWIN_USER_TEMP_DIR` • kSBXProfilePureComputation – all OS services are restricted An application can utilize one of these constants to restrict capabilities in spawned processes or threads, minimizing the potential damage that can occur in the event that the process is compromised. Figure 1 shows an example implementation of the kSBXProfileNoWrite profile in code: Figure 1. #include  #include  #include  #include int main() { int sb, fh; char **errbuf; char rtxt[255]; char wtxt[255] = “Sandboxed you aren’tnn”; // init our sandbox, if we don’t return 0 then there’s a problem sb = sandbox_init(kSBXProfileNoWrite, SANDBOX_NAMED, errbuf); if ( sb != 0 ) {         printf(”Sandbox failedn”); return sb; }; fh = open(”test.txt”, O_RDONLY); if ( fh == -1 ) { perror(”Read failed”); } else { read(fh, rtxt, 255); close(fh); printf(”FileContents:n %sn”, rtxt);  }; fh = open(”test.txt”, O_RDWR | O_CREAT, 0000644); if ( fh == -1 ) { perror(”Write Failed”); } else { write(fh, wtxt, strlen(wtxt)); close(fh); printf(”Successfully wrote file!n”); } return 0; }     Compiling and running this code returns the following results: % ./sandBoxTest FileContents:  hello               Write Failed: Operation not permitted So, even though our POSIX permissions allows for read/write access to the file, the sandbox prevents it, regardless of user. Running the program even with root privileges yields the same results.  Currently, the options provided by Apple are very all-or-nothing, particularly in the area of file system restrictions. In this way, Seatbelt acts more as a clumsy broadsword, lopping off functionality in large chunks at a time for the sake of security. In this form, Seatbelt has minimized use outside of very vertical applications or the increasingly rare applications that don’t utilize network communication in one way or another. Though these limitations will significantly limit widespread adoption, I believe it would be a mistake for a developer to shrug off Seatbelt as a whole. Luckily, Seatbelt has an alternate application, though currently it is not officially supported. As I mentioned earlier, it is possible to apply sandbox restrictions to any pre-complied executable at runtime. This is done via the sandbox-exec binary, and uses predefined profiles housed at /usr/share/sandbox which provide for fine-grained control of resources. These profiles use a combination of allow/deny rules in combination with regular expressions to specify system resource access. There are numerous control points, such as network sockets, signals, sysctl variables, forking abilities, and process execution, most of which can be tuned with fairly decent precision by utilizing a combination of regex and static inclusion sets. Filesystem objects and processes are identified via POSIX paths; there currently is no target validation performed ether via checksums or digital signing.   Figure 2 shows a sample sandbox profile that can be applied to restrict an application from making outbound communications and restricts file system writes to temporary directories and the user’s preferences folder. The ‘debug deny’ line tells seatbelt to log all policy violations. This proves to be very useful in determining filesystem and network activity by an untrusted program. It facilitates a quick-and-easy way to do basic forensic testing on any program acquired from an untrusted source. Figure 3 shows example log violations of a network-outbound violation, and of a file-write violation, respectively. To apply a sandbox profile to a standard application bundle you must pass sandbox-exec the path of the mach-o binary file which is typically located in ‘Contents/MacOS/’, relative to the application’s bundle. You can specify a sandbox profile by name using the -n flag if the profile resides in /usr/share/sandbox, or you can specify a full path to a profile with the -f argument. Carbon applications may require the LaunchCFMApp wrapper to properly execute. See figure 4 for example syntax for both Cocoa and Carbon Applications. Figure 2. Example sandbox profile (version 1) (debug deny) (allow default) (allow process*) (deny network-outbound) (allow file-read-data file-read-metadata   (regex "^/.*")) (deny file-write*         (regex "^/.*")) (allow file-write*         (regex "^/Users/johndoe/Library/Preferences.*")) (allow file-write* file-read-data file-read-metadata   (regex "^(/private)?/tmp/")) (import "")     Figure 3. Example log entries from TCP and filesystem write violations 3/4/08 12:15:10 AM kernel dig 79302 NET_OUTBOUND DENY l= unavailable r= UDP 1 (seatbelt)  3/4/08 12:43:05 AM kernel sh 79147 FS_WRITE_DATA SBF /Users/Shared/test.txt 13 (seatbelt)  Figure 4. Using launchd to sandbox cocoa and carbon applications.   Cocoa % sandbox-exec -n localonly /Applications/ Carbon % sandbox-exec -n localonly /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Microsoft Office 2004/Microsoft Word Unfortunately, the system seems to be far from finalized, and even some example profiles provided by Apple do not seem to be completely functional, or contain unimplemented control points. One example of this is seen when trying to implement IP-based network restrictions. Apple provides example entries for layer3 filtering in the included profiles, but they are commented-out and illicit a syntax error when ran. Additionally, Apple has a rather ominous warning in each of it’s provided profiles, stating that current profiles are deemed to be Apple System Private Interfaces, and may change at any time. However, that’s no reason to completely ignore the technology. Given what has currently been implemented, and taking into consideration control points which are alluded to by Apple’s own imbedded comments, Seatbelt is showing significant promise to provide very fine-grained resource access capabilities. By utilizing these restrictions, applications and users can ensure that even in a worst-case scenario, possibilities for errant/hijacked process damage becomes mitigated and compartmentalized. There are many real-world situations where this type of access control model fits very well, particularly in complement to standard DAC systems: they can be used to mitigate privilege escalation opportunities for shell users, to confine behavior conformance of processes to defined resources (and there by protect against hacked processes), or as a forensic tool to determine software malfeasance. By providing these type of capabilities through the Seatbelt policy module, and by providing a path towards implementing more complex MAC policy modules, Leopard’s new MAC framework ushers in a new level of security and access control capabilities for OS X.

May 22nd, 2008

Posted In: Articles and Books, Mac Security

Tags: , , ,

Originally posted at RepToolsâ„¢ 2008318, Inc. is proud to announce the immediate availability of our flagship software product, RepToolsâ„¢ 2008. RepToolsâ„¢ 2008 is a customer relationship management (CRM) suite developed specifically for the entertainment industry. RepToolsâ„¢ 2008 has nine integrated modules that are designed to efficiently manage all of the information businesses need to manage sales forces automation, asset management, and customer relationships from the beginning to the end of production. With instantaneous access to every aspect of the production process and comprehensive metrics for detailed analysis, RepToolsâ„¢ 2008 will let you worry about what matters the most: your customers. Over 100 New Features:
  • Document Management – RepToolsâ„¢ 2008 has an all new document management system that will automatically organize your storyboards, bids, treatments, callsheets, location photos, and more.
  • Completely New Interface – Built to be faster over your network and keep you more productive than ever before.
  • New QuickFind – Now you can find any of your projects, contacts, or bids in seconds.
  • Live Filters – See only what you decide is relevant and prevent information overload from bogging down your workflow.
For more information about RepToolsâ„¢ 2008 and how it can dramatically increase the productivity of your business, please visit or call us toll-free at (888) 347-3318.

May 20th, 2008

Posted In: FileMaker

Tags: ,

I originally posted this at So you need to empty your cache resolver, but you fire up your handylookupd but you’re getting a command not found error. What to do… Try dscacheutil, which let’s you do so very much more than lookupd. For example, using the -cachedump allows you to dump an overview of the cache contents. -cachedump has a slew of flags to get pretty granular with the output such as -entries and -buckets-configurationallows you to access detailed information about your search policy. -statistics allows you to view detailed information on statistics of calls. Examples of using these commands: Emtpy the DNS Cache Resolver: dscacheutil -flushcache Dump cache with user entries: dscacheutil -cachedump -entries user Lookup all the users on a system: dscacheutil -q user

November 24th, 2007

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , ,

I originally posted this at Apple has been slowly winning over a lot of traditional Unix and Linux converts. This new breed of switcher is after a cool shell environment. In Leopard, Apple has upgraded to provide a whole slew of new features that are sure to continue winning new converts. Let’s just take a look at a few of them: Secure Keyboard Entry – Prevent other applications from detecting keystrokes used in terminal. Enable this using the Terminal menu. Tabbed Interface – I always have 3 shell windows open. That’s how I roll. But with the new tabbed interface (which you can access using the Command-T keystroke) I find that I’m using two shell windows with 3 tabs each. This gives me the ability to have a man page or process list on one side of my screen while being able to run other commands on the other side. You can fire up 2 shell windows and then open as many tabs as you like. Export Settings – This isn’t new in Leopard, but what is new in Leopard is that the tabs get exported along with window positions, layouts, themes and backgrounds. Themes – Glass, Homebrew, Novel, Red Sands – these themes allow you to use prebuilt templates for how you view your shell. These include background, text color, transparency. Can you imagine Steve sitting in his office at Apple dinking around with the Homebrew theme? Window Groups – A group of windows with a saved location, tabbed layout, shell configuration and settings. Terminal Inspector – Switch themes on the fly, view running process and increase the columns and rows of a shell environment. Titles – Set titles for your terminal windows so you can remember what was where.

November 15th, 2007

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , ,

I originally posted this at To answer all those questions like “How do I create a share point now?” Apple has been kind enough to post the documentation for Leopard Server at: All of the new services are documented per Apple standards, so happy reading!

November 9th, 2007

Posted In: Mac OS X Server

Tags: , ,

I originally posted this at ZFS was released by a team at Sun in November of 2004. The name stands for “Zettabyte File System”. ZFS is a 128-bit file system, so it can store 18 billion billion (18.4 × 1018) times more data than current 64-bit systems. We’re not going to sit here and do the math for that but you are more than welcome to figure out what the theoretical size is at that point – all we can say is that it’s friggin’ huge. Traditional file systems reside on single devices and require a volume manager to use more than one device to generate a logical or physical volume. ZFS is built on top of virtual storage pools called zpools. A zpool is constructed of virtual devices called vdevs. Vdevs are constructed of block devices that include files, partitions, or drives. Block devices within a vdev can be configured in a variety of different manners, depending on the needs of a user. The storage capacity of all vdevs is available to all of the file system instances in the zpool. This is similar in some ways to how Xsan builds volumes, but more customizable and without a requirement for vdevs to be based on Fibre Channel storage in order to be accessible by multiple hosts. Quotas can be set to limit the amount of space a file system instance can occupy and a reservation can be set to guarantee that space will be available to a file system instance. This gives some nice features to those wanting to limit access for some volumes while still making sure other volumes have the space that will be required for planned future possible expansions. Other features of ZFS include: snapshots, write-cache, filesystem based encryption (in Alpha stage of development) and checksumming. While users of Leopard may be disappointed in the fact that ZFS did not make it in the final build, giving greater volume sizes and more features for volume management, rest assured that Apple will be thoroughly testing any new file systems before making them available to the public and that with something as precious as a file system, if it wasn’t ready for prime time then it’s good that it wasn’t included with Leopard. ZFS is still going through changes and is not a completed or matured project by any stretch of the imagination. In /Library/FileSystems you will see that ZFS is not present but the framework for future ZFS is present which can be seen by the introduction of some ZFS binaries to the system. So keep a look out for ZFS in the future and maybe even an SDK from SUN on using it at some point.

November 6th, 2007

Posted In: Mac OS X

Tags: , , , , ,

I originally posted this at Most screen savers just waste power. Might as well just put your computer to sleep. But if you want to use a screen saver and you want to do something good for humanity then check out one of these: – Join more than 300,000 other computing nodes and dedicate your computing power to finding new AIDS treatments – Improve climate prediction models with the University of Oxford – Help George Woltman be the first to find a 10 million-digit prime – Test Einstein’s theory of gravitational waves

July 3rd, 2007

Posted In: Articles and Books, personal


I originally posted this at Article about 318 on, focusing on a project we did integrating Kerio to replace Microsoft Exchange, giving our client the ability to centralize all of their server assets into an Open Directory environment while still using MAPI to provide groupware components to their user base, have handheld devices that sync with their Calendar/Mail/Contacts and of course, use the standard Exchange features of mail, etc. Good stuff:

June 16th, 2007

Posted In: Articles and Books, Business, Consulting, Kerio, Mac OS X, Microsoft Exchange Server

Tags: , , ,

I originally posted this at Sometimes a drive fails, or a RAID controller goes down on an array with a redundant drive and the parity on a RAID must be rebuilt. In other words, if you loose a drive in a RAID 5, RAID 1, RAID 0+1 or RAID 3 array you will be left with a degraded RAID (also referred to as a critical RAID) unless you have configured your Xserve RAID to use a hot spare. If you are using a hot spare on the channel of the failed drive the RAID will begin to rebuild itself automatically. If you are not using a hot spare, upgrading your degraded RAID back to a healthy state should happen as quickly as possible to avoid data loss. In the event of a second drive failure on the array most of the data could be lost – and Murphy’s Law is evil when it comes to RAIDs. The data should be backed up as quickly as possible if it has not already been backed up. Once the data is backed up, you should perform a rebuild of the parity for the array. The partiy is rebuilt based on the data that is on the array. This does not fix any issues that may be present with actual data. In other words, if you were using the Xserve RAID as a local volume it would only repair issues with the array and not also perform a repair disk on the drives. In an Xsan any data corruption could force you to rebuild you volume from the LUNs. You would not need to relabel the LUNs, but you may have to rebuild your volume In many situations you will be able to simply swap the bad drive out with an identical good drive and configure it as a hot spare. Then the Xserve RAID will automatically begin rebuilding the array, moving it from a degraded state into a healthy state. However, there are often logical issues with drives and arrays. Also, hot spares do not always join the degraded array. In these situations you may need to manually rebuild an array. To do this: Silence the alarm on the Xserve RAID. Verify that you have a clean backup of your data. Verify that you have a clean backup of your data again or better, have someone else check as well. Open up your trusty Xserve RAID Spare Parts Kit and grab the spare drive module. Remove the drive module that has gone down (typically the one with the amber light). Install the new drive in your now empty slot. Open RAID Admin from the /Applications/Server directory. Click on the RAID containing the damagemed array. Click on the Advanced button in the toolbar. Enter the management password for the Xserve RAID you are rebuilding the parity for. Click on the button for Verify or Rebuild Parity and click on Continue. Select the array needing to be rebuilt. Click Rebuild Array and be prepared to wait for hours during the rebuild process. It is possible to use the array during the rebuild process – although if you don’t have to use the array it is probably best not to as you will see a performance loss. During the rebuild the lights on the drive will flash between an amber and a green state. Once the rebuild is complete, perform a Verify Array on the RAID. Verify the data on the volumes using the array. Order a new drive to replace the broken drive in your Xserve RAID Spare Parts Kit. If the rebuild of the data does not go well and the array is lost then you will likely need to delete the array and readd it. This will cause you to loose the data that was stored on that array and possibly on the volume, so it can never hurt to call Apple first and see if they have any more steps you can attempt. This is one of the many good reasons for backing data up. Just because you are using a RAID does not mean you should not back your data up. The Verify Array can also be used to help troubleshoot issues with corrupted arrays. This process has been tested using firmware 1.5 and below for Xserve RAIDs.

April 4th, 2007

Posted In: Xsan

Tags: , ,

Next Page »