Tiny Deathstars of Foulness

Encrypting a volume in OS X Mountain Lion couldn’t be easier. In this article, we will look at three ways to encrypt OS X Lion volumes. The reason there are three ways is that booted volumes and non-booted volumes have different methods for enabling encryption. The third way to enable encryption on a volume is to do so through Encrypting Attached Storage For non-boot volumes, just control-click or right-click on them and then click on Encrypt “VOLUMENAME” where the name of the volume is in quotes.

Encrypting a Volume in Mountain Lion

When prompted, provide an encryption password for the volume, verify that password and if you so choose, provide a hint.

Setting an Encryption Password For a Volume in Mountain Lion

Once the encryption process has begun, the entry previously clicked on says Encrypting “VOLUMENAME” where the name of the volume is in quotes.

Viewing the Encryption Status in Mountain Lion

Before you can encrypt a volume from the command line you must first convert it to CoreStorage if it isn’t already. As volumes on external disks aren’t likely to be CoreStorage, let’s check using diskutil along with corestorage and then list: diskutil corestorage list Assuming your volume was already formatted with a non-corestorage format and isn’t listed, locate the volume and document the disk identifier (in this case disk2s3). Then, run diskutil corestorage along with the convert verb and the disk, as follows (no need to run this command if it’s already listed): sudo diskutil corestorage convert disk2s3 The output should look similar to the following: Started CoreStorage operation on disk2s3 Reco Resizing disk to fit Core Storage headers Creating Core Storage Logical Volume Group Attempting to unmount disk2s3 Switching disk2s3 to Core Storage Waiting for Logical Volume to appear Mounting Logical Volume Core Storage LVG UUID: 19D34AAA-498A-44FC-99A5-3E719D3DB6FB Core Storage PV UUID: 2639E13A-250D-4510-889A-3EEB3B7F065C Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31 Core Storage disk: disk4 Finished CoreStorage operation on disk2s3 Reco Once converted, the LV UUID (LV is short for Logical Volume) can be used to encrypt the logical volume using a password of crowbar to unlock it: sudo diskutil corestorage encryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar The output is similar to the following: Started CoreStorage operation on disk4 Reco Scheduling encryption of Core Storage Logical Volume Core Storage LV UUID: 4CC5881F-88B3-42DD-B540-24AA63952E31 Finished CoreStorage operation on disk4 Reco According to the size, this process can take some time. Monitor the progress using the corestorage list option: diskutil corestorage list In all of these commands, replace core storage w/ cs for less typing. I’ll use the shortened version as I go. I know that we rarely change passwords, but sometimes it needs to happen. If it needs to happen on a core storage encrypted volume, this can be done from the command line or a script. To do so, use diskutil cs with the changevolumepassphrase option. We’ll use -oldpassphrase to provide the old password and -newpassphrase to provide the new passphrase. diskutil cs changeVolumePassphrase FC6D57CD-15FC-4A9A-B9D7-F7CF26312E00 -oldpassphrase crowbar -newpassphrase hedeservedit I continue to get prompted when I send the -newpassphrase, so I’ve taken to using stdin , using -stdinpassphrase. Once encrypted there will occasionally come a time for decrypting, or removing the encryption, from a volume. It’s worth noting that neither encrypting or decrypting requires erasing. To decrypt, use the decryptVolume verb, again with the -passphrase option: diskutil cs decryptvolume 4CC5881F-88B3-42DD-B540-24AA63952E31 -passphrase crowbar FileVault 2: Encrypting Boot Volumes Boot volumes are configured a bit differently. This is namely because the boot volume requires FileVault 2, which unifies usernames and passwords with the encryption so that users enter one username and password rather than unlocking drives. To configure FileVault 2, open the Security & Privacy System Preference pane and then click on the FileVault tab. Click on the lock to make changes and then provide the password for an administrative account of the system. Then, click on “Turn On FileVault…”
Enable FileVault In Mountain Lion

Enable FileVault In Mountain Lion

When prompted with the Recovery Key, document it and then click on
Documenting the FileVault 2 Recovery Key

Documenting the FileVault 2 Recovery Key

Choose whether to restore the recovery key with Apple. If you will be storing the key with Apple then provide the AppleID. Otherwise, simply click the bullet for “Do not store the recovery key with Apple” and then click on the Continue button.
Dealing With Recovery Keys in FileVault 2

Dealing With Recovery Keys in FileVault 2

When prompted, click on Restart to reboot and be prompted for the first account that can unlock the FileVaulted system.
Rebooting To Start FileVault 2 Encryption

Rebooting To Start FileVault 2 Encryption

Once encrypted, the FileVault tab in the Security & Privacy System Preference pane shows the encryption status, or percent during encryption. Use the Enable Users… button to enable additional accounts to unlock the volume (note: by default accounts cannot login until their account has been added here).
Allowing Users To Boot The Computer

Allowing Users To Boot The Computer

That’s it. Managing FileVault 2 using the System Preferences is about as easy as it can get. But for those who require mass management, Apple has provided a tool called fdesetup for that as well. Using fdesetup with FileVault 2 FileVault 2 now comes with a nifty configuration utility called fdesetup. To use fdesetup to encrypt the boot volume, first check FileVault’s status by entering the fdesetup command along with the –status option (wait, no — required any more!): fdesetup status As with most other commands, read the help page before starting to use just in case there are any changes to it between the writing of this article and when you kick off your automated encryption. Done using the help verb: fdesetup help After confirming FileVault is off, enable FileVault with the enable option, as follows: sudo fdesetup enable Unless additional parameters are specified, an interactive session prompts for the primary user’s short name and password. Once enabled, a Recovery key is returned by the fdesetup command. You can also cancel this by just hitting Control-C so we can look at more complicated iterations of the command. It should be recorded or otherwise stored, something easily done by mounting in a script (e.g. a write-only share in a script for key escrowing). If more complicated measures are needed, of course check out Cauliflower Vest at As fdesetup is in its first version, I find it amusing that it’s actually 1.3 as indicated using: fdesetup version Now, if you run fdesetup and you’ve deployed a master keychain then you’re going to have a little more work to do; namely point the -keychain command at the actual keychain. For example: sudo fdesetup enable -keychain /Library//Keychains/FileVaultMaster.keychain To define a certificate: sudo fdesetup enable -certificate /temp/filename.cer Adding additional users other than the one who enabled fdesetup is a bit different than the first: sudo fdesetup add -usertoadd robin To remove users, just remove them with a remove verb followed by the -user option and the username: sudo fdesetup remove -user robin The remove and add options also offer using the -uuid rather than the username. Let’s look at Robin’s uid : dscl . read /Users/robin GeneratedUID | cut -c 15-50 Yes, I used cut. If you have a problem with that then take your judgmental fuc… Nevermind. Take that GUID and plug it in as the uuid using the -uuid option. For example, to do so with the remove verb: sudo fdesetup remove -uuid 31E609D5-39CF-4A42-9F24-CFA2B36F5532 Or for good measure, we can basically replicate -user w/ -uuid for a nice stupid human trick: sudo fdesetup remove -uuid `dscl . read /Users/robin GeneratedUID | cut -c 15-50` All of the fdesetup commands can be run interactively or using options to define the variables otherwise provided in the interactive prompt. These are defined well in the man page. Finally, let’s look at -defer. Using -defer, you can run the fdesetup tool at the next login, write the key to a plist and then grab it with a script of some sort later. At logout, the user will get prompted for a sudo fdesetup enable -defer /temp/fdesetupescrow.plist Or define users concurrently (continuing to use the robin test user): sudo fdesetup enable -user robin -defer /temp/fdesetupescrow.plist FileVault accounts can also use accounts from Directory Services automatically. These need to synchronize with the Directory Service routinely as data is cached. To do so: sudo fdesetup sync This is really just scratching the surface of what you can do with fdesetup. The definitive source for which is the man page as well as a nicely done article by Rich Trouton (who I think I will start calling Trouty-mouth after having watched the Glee episode where one of the girls says that). Encrypting Time Machine Backups The last full disk encryption to discuss is Time Machine. To encrypt Time Machine backups, use Time Machine’s System Preference pane. The reason for this being that doing so automatically maintains mounting information in the Operating System, rather than potentially having an encrypted drive’s password get lost or not entered and therefore not have backups run. To enable disk encryption for Time Machine destinations, open the Time Machine System Preference pane and click on Select Backup Disk… From the backup disk selection screen, choose your backup target and then check the box for “Encrypt backups”. Then, click on Use Disk.
Encrypting Time Machine Volumes

Encrypting Time Machine Target Volumes

At the overlay screen, provide a backup password twice and if you would like, a hint as to what that password is. When you are satisfied with your passwords, click on the Encrypt Disk button.
Configuring The Password For A Time Machine Backup

Configuring The Password For Encrypted Time Machine Backups

Now, there are a couple of things to know here. 1. Don’t forget that password. 2. If you use an institutional FileVault Key then still don’t forget that password as it will not work. 3. Don’t forget that password… Conclusion Encrypting data in OS X can take on other forms as well. The keychains encrypt passwords and other objects. Additionally, you can still create encrypted dmgs and many file types have built in encryption as well. But the gist is that Apple encrypts a lot. They also sandbox a lot and with the addition of gatekeeper are code signing a lot. But encrypting volumes and disks is mostly about physical security, which these types of encryption provide a substantial solution for. While all this security might seem like a lot, it’s been in Apple’s DNA for a long time and really security is about layers and the Mac Systems Administrator batbelt needs a lot of items to allow us to adapt to the changing landscape of security threats. OS X is becoming a little more like iOS as can be expected and so I would suspect that encryption will become more and more transparent as time goes on. Overall, the options allow encrypting every piece of data that goes anywhere near a system. The mechanisms with which data is now encrypted are secure, as is the data at rest. Once data is decrypted, features like Gatekeeper and the application layer firewall supplement traditional network encryption to keep well secured.

July 27th, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

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

Microsoft released Service Pack 2 to Microsoft Office 2008 for Mac earlier this week.  Once you have installed Service Pack 2 you may notice the new Open from Document Connection File menu item for office applications, or you may notice the new application called Microsoft Document Connection located in your /Applications/Microsoft Office 2008 folder.  These are all part of Microsoft’s overall Software+Services strategy: provide a cloud type of environment that is able to sustain the software that you purchase from them.  In this case it could be a private document storage “cloud” running on a SharePoint server or it could be a more public environment running in the Office Live environment. We’ll cover SharePoint integration some other time, but for now, let’s look at the Live environment. Before you setup your computer, first login to your Microsoft Live account at Once you are signed in, click on the More menu and click on Office Live. If you see a button for Get Started for Free, click it; otherwise you should be looking at a screen with an icon in the left column for New Workspace. Click it and then type something that indicates a project or a group of documents you might upload. For example, I’ll just type Mac OS X Security 2nd Edition. Now that you have a workspace, open up the Microsoft Document Connection application in your Office directory. From here, click on Add Location… and then click on Sign In to an Office Live Workspace… At the dialog box, enter the name and password you use to log into Microsoft Live, clicking Save when you’re done. Now you should see the name of your live account in the Document Connection screen, along with any workspaces you’ve created. You can drag documents into this screen, double-click them to open or control-click them to edit (and you can edit from non-Microsoft applications). At this point you have something similar to Jungle Disk or another application you use to access a cloud service from a Mac. But Document Connection isn’t just about one user accessing documents. It supports sharing documents between users, commenting on documents and even document check-in and check-out. The portal is where you setup most of the Sharing: use the share button, type the address of who you want to share to, they can then access via the portal or using Document Connection with their own account. Commenting is also available in the portal, much as with a solution like Final Cut Server. Document check-in and check-out seems to require SharePoint and not be a feature of Office Live, but I’ll let you know if I can find a way to do it. Overall, this is a great addition. Some other products are more mature, but as usual, Microsoft has taken the best from a number of competitors and made an extremely simple to use and intuitive sandbox. The uploads and downloads fail at times. The portal relies on constant communication from Silverlight so sometimes it throws an error. But those are minor issues. This is a great new product that I look forward to integrating into a number of environments. I’ll get to the SharePoint side in the next few days and do a write-up on it as well!

July 21st, 2009

Posted In: Mac OS X, Microsoft Exchange Server

Tags: , , , , , , ,

Playing with Sandbox can be tricky. The other day my own box (luckily one not FDE’d) started to kernel panic and I’d just activated about 12 sandbox profiles. To fix, I booted to single user mode (Command-S), mounted the drive (using the command mount -uw /). Then I did a find for all *.sb files (assuming you use the sb extension for your sandbox files) touched that day, deactivated them and rebooted. Oddly, still no dice. Did I miss one? Next, just to verify it was a sandbox issue, I went back into single user mode, remounted the volume and used this command to move the Seatbelt kernel extension to a temp directory. mv /System/Library/Extensions/Seatbelt.kext /Temp/Seatbelt.kext That fixed the problem. Now I’m really curious. Put it back, verify permissions, still busted. Next, boot without it and try to manually kextload it. Bam, still busted. So after about an hour of trying to figure it out, I grabbed a Seatbelt.kext file from another host and popped it into the /System/Library/Extensions directory. Viola, issue resolved. Not sure how/why, but my Seatbelt.kext was corrupt. No logs of disk/file corruption. I can’t imagine a sandbox profile could corrupt the kernel extension, but it seems like too much an anomaly that I was working on sandbox profiles when it got corrupted…

April 13th, 2009

Posted In: Mac OS X, Mac Security

Tags: , , , ,

Beau and I will be giving a talk at MacWorld on Friday. It will be all about Sandbox, the Mandatory Access Control facility from Apple. So if you’re going to be around then you should definitely check it out. Also, Zack will be giving one on Thursday at 1. His will be on recovering from laptop theft. Both talks will be in the security track of the MacIT portion of MacWorld.

December 28th, 2008

Posted In: Articles and Books, Mac Security, public speaking

Tags: , ,

Leopard represents a massive leap forward in security features included with Mac OS X. As the needs of users of OS X have matured so has the ability for systems administrators, developers and end users to secure their systems. One of new security features is Sandbox. Since it’s inception, Mac OS X has had permissions that can be applied to files allowing the ability to block access to specific applications. But Sandbox gives you the awesome new ability to apply permissions to what specific applications can have access to. In this session we will review what an application can access and how to harness Sandbox to restrict access to networking, TCP/IP and file access. We will also cover the Sandbox profiles that are already included in the system and review how to edit and manage them.

October 10th, 2008

Posted In: Articles and Books, public speaking

Tags: ,

MacWorld tickets are on sale.  While I do not know who all the speakers will be I do know that 318 will be there and Beau and I will be giving a presentation on sandbox.  🙂

October 2nd, 2008

Posted In: public speaking

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: , , ,