Jump to content

Mac the Knife

  • Content count

  • Joined

  • Last visited

About Mac the Knife

  • Rank
    InsanelyMac Protégé
  1. How to Enable Legacy FileVault on Mac OSX 10.7 Lion

    In the past 72 hours it has been discovered that there is a major security flaw in Mac OSX 10.7.3. It deals specifically with the use of Legacy FileVault in OSX 10.7. Legacy FileVault is the older “Home Directory only” encryption used in Mac OSX 10.6.x and prior. Legacy FileVault would only be active in Mac OSX 10.7.x if you had enabled FileVault in 10.6.x (or prior), upgraded to 10.7, and then opted NOT to convert your old Home Directory only encryption to the newer Full Disk Encryption FileVault of 10.7. There is not an Apple Approved method or GUI to enable or create a new Legacy FileVault on 10.7.x. HOWEVER… I produced a guide back on October of 2011 that outlined how to manually enable and create a new Legacy FileVault in Max OSX 10.7.x Lion (http://www.taborcg.c...-osx-10-7-lion/). As I started in the guide there are several reasons why Legacy FileVault might have an advantage over the new FileVault, including true security on multiuser systems and having good crypto security with Mac OSX 10.7 Lion running on non-approved hardware (i.e. Hackintosh OSX86) The bug effects both use cases of Legacy FileVaults from upgrades AND manually created Legacy FileVaults using the aforementioned guide. The has only surfaced after the 10.7.3 update. It would appear that some bonehead at Apple left a debugging flag turned on that records both the username and password IN CLEAR TEXT to a log file whenever an encrypted Legacy FileVault disk is mounted. This does not appear to log the password when new Full Disk Encryption FileVault disks are mounted at boot time, and does not log when encrypted DMG files are mounted, only when Legacy FileVault disks are mounted at the point of user logon. The username and password in clear text are stored int he log file: /var/log/secure.log (and it’s subsequent rolled over backups .bz2) The easiest way to view and work with the file is via the terminal and elevating yourself to superuser (root) status. From the terminal type: sudo su - and enter your password (assuming you are a user with administrative privileges) Once you see the root# prompt, change directories to the system log location. cd /var/log/ From here you can do an ls to view the files, or simply cat or nano the secure.log to view it. nano ./secure.log Look for one of the offending lines like: May 4 23:41:56 Home-Mac-Pro authorizationhost[128]: DEBUGLOG | -[HomeDirMounter mountEncryptedHomeWithURL:attributes:dirPath:username:] | about to call DIHLFVMount. urlAttribute = /Users/.mckinleytabor/mckinleytabor.sparsebundle, password = mysupersecrettinfoilhatpasswordthatitwouldtakelikeamillionyearstobruteforceandnothisisnotit, mountPointParent = /Users, homeDirPath going to the DIHLFVMount call = /Users/mckinleytabor Conversely, you can also do a Control-W in nano and just search for your password, if you are using Legacy FileVault and 10.7.3, it will be there. (Just as an aside, it’s always odd to SEE my passwords written out. I (and you should) NEVER write down a password, so to me, my passwords are not words, they are elements of my imagination that correspond to muscle memory. My brain does not file them away as actual text or words. So to them written out is an oddly dissociative experience.) The end of result of this debacle is that ANYONE with root permissions (i.e. any other user with Administrative rights) or anyone who physically extracts the harddrive and reads it with another computer, has easy access to the passwords. WORD AROUND Apple programers are going to need to stop dog paddling around in their corporate wall garden swimming pool full of $100 bills and fix this. But until then there is a quick and dirty way to be a bit safer. We can run a cron job to scrub the offending files off the system. It’s not perfect, but it will work. Doing this will remove your ability to refer to the secure.log file to diagnose any issues logged there, but to be honest prior to today, I have never had to use this file, so not having it is not a problem for me. Use with your own discretion. Cron, for those of you who do not know, is the *nix way of running programs and scripts on a timmer. You can add a “cron job” with the following command, which will open a text editor. crontab -e In most cases this will only up the text editor vi (or vim). If you have never worked with cron, you should be looking at a blank page. You will need to add a line to this page, that will be the command and timings for the “cron job”. Vi is a very powerful text editor (which you should take the time to learn) but for our proposes today, you only need to know a few commands. When you want to type text into a document with vi you must first type “i” to start editing the file. (This is the command to insert text) Enter the following line into vi: * * * * * srm -frmz /var/log/secure.log* && ln -s /dev/null /var/log/secure.log What does this line mean? The five space separated asterisks are the timing codes telling cron when to run the command. As you may now asterisks in *nix are short hand to mean “anything/everything” (which is why *nix can mean Unix or Linix). The first asterisk for the minute of the house, which in our case is EVERY minute of the hour. The second asterisk is the hour of the day, which in our case is EVERY hour of the day. The third asterisk is the day of the month, which in our case is EVERY day of the month. The four asterisk is month of the year, which in our case is EVERY month of the year. The fifth asterisk is day of the week, which in our case is EVERY day of the week. So in a nutshell, five asterisks mean to run the command every minute until the end of time. The command is everything starting with “srm”. Srm is a *nix command meaning “secure remove”. Unlike the normal “rm” command which simply unlinks files, srm scrubs them off the disk so that they are highly unlikely to be recovered via forensic means. The “-frmz” switches tells srm to: Force the process even if there might be a lock on the file (“f”), Run Recursive so that it grabs any files in lower directories (“r”) (not strickly needed in our case, but better safe than sorry), Medium scrubbing of 7 US DOD random rewrites over the top of the files in question (“m”) and finally, Zero out the file location with 00000 (“z”). The final part of the command “/var/log/secure.log*” tells srm what files to scrub off the drive. In this case it will be the secure.log and any of it’s backed up .bz2 predecessors. PLEASE note that the file asterisk in the command is important, and that it’s placement at the end of the command WITHOUT any spaces before it is important. As I said, * is short hand for anything/everything. When the asterisk is attached to a file, like secure.log*, it means to get every file who’s name begins with secure.log. Putting a space between the secure.log and the * might result is some unwanted behavior, like scrubbing off the secure.log, and then every other file in the directory you are running srm from. Not good to scrub your entire drive if you happen to be sitting on the root (/) directory. The “&&” is again short hand for “also run this command”, a simple way to put to separate commands on the same line to be run consecutively. The next command is “ln” which in *nix allows us to “link” files. The switch “-s” means to Symbolically link the file (as apposed to a hard link, which is not possible with what we are about to do). The next two times are the files we are linking. In this case we are linking the systems /dev/null to /var/log/secure.log. The system file /dev/null is a *nix special file used when you want to transfer data into nothing (i.e. delete it). It’s a place that can be used in scripts to dump unwanted automatic data, or provide a filler when you are required to have something but want nothing (quite existential nihilistic isn’t it). Here because we are linking /var/log/secure.log to /dev/null, anytime the system tries to write out data to the file /var/log/secure.log, it goes “nowhere”, meaning it is never written onto the disk, it is never recorded. Once you have entered the cronjob, type Esc twice to exit the editing mode of vi, then type the following line to save and exit vi: :wq (note the colin is important) After less than 60 seconds you can do an ls -la command and all of the offending secure.log and secure.log.*.bz2 files will be gone, replaced by a file /var/log/secure.log pointing to /dev/null. Optional If you want to test the command PRIOR to running it in a cronjob, you can simply run: srm -frmz /var/log/secure.log* && ln -s /dev/null /var/log/secure.log From any command propt and it should scrub the log file off the system. Into the Furture… Some things to be concerned about. Apple released the 10.7.3 update on February 1, 2012. This means that this bug has been floating around for from 64 days. It was publicized within the last 3 days, but Apple still has their head in the sand and has not acknowledged the problem. It’s possible that this bug could have been exploited in the last 9 weeks. Remember the “FlashBack” Mac Virus has been active durning this time, and it did have root/administrative privileges. (Thought I want to stress that there has not been any confirmation that FlashBack was exploiting this bug, I only bring it up to illustrate that it COULD have exploited it.) If you are using TimeMachine or any other Full system backup, your /var/log/secure.log* files have been backed up and are floating around where ever. I suggest you start a hunt to find them and srm them out of existence. Now is a GREAT time to charge your password strategy (and again after the bug is fixed). If your password has been compromised, then changing it AFTER you build a job to srm the log files will help negate the breach. The combination of srm and ln in the cronjob is a belt a suspenders approach to the problem. (well, I guess you could say its a belt, suspenders, and jockstrap with cup approach). This is because I do not know how well the /dev/null -> /var/log/secure.log link will survive the automatic roll over of the logs, nor how it will survive any incremental updates from Apple. Because this is root running the cronjob it will be completely independent of the user. If for some reason the normal function of /var/log/secure.log and it’s roll overs is restored, the cronjob “should” kill it, scrub the files, and place the link back to /dev/null with the need for user intervention. I would advice that you wait 90 to 120 at the login screen each time you boot the system to allow for enough time for the script to do it’s job BEFORE you login. This way your password wil never be written to the disk, and the srm become redundant, but a safety catch. This is the long approach, if someone knows how to disable this debug flag, or turn off /var/log/secure.log logging altogether, I’m open to suggestions. Yes, if another user with admin/root privileges undoes your cronjob and removes your link to /dev/null, the system will go back to being broken. In very secure environments, I would respectfully submit that two users with admin/root rights on the same box is inherently insecure, but I’m not maganing your use case, so there may be a good reason for you needing it. According to some things I have read, this bug is fixed in the lastest developer build of Mac OSX 10.7.4 Lion. But we are a long way from that release, so maybe Apple will issue an interim patch. In the mean time add period checks to the log file to insure that clear text passwords
  2. How to Enable Legacy FileVault on Mac OSX 10.7 Lion

    Yes, once you copy everything into the sparsebundle and you are sure it's logging into the sparsebundle you can delete every file and folder in the home directory EXECPT the sparsebundle. I'm always hesitant to advise people to "delete" anything, simply out of fear of data loss. But if you feel comfortable that you've got everything backed-up and that the FileVault is working then slash and burn.
  3. How to Enable Legacy FileVault on Mac OSX 10.7 Lion

    Hmm, please don't take this the wrong way, but you might have a typo in the command. OR more likely the variables set earlier on in the guide for UID and GID were lost. Try this.. Redo the guide, but just before the hdiutil line rerun this: echo Username $SBUSERNAME - UserID $SBUID GroupID $SBGID You "should" get the same results from it as you did the first time, something like: Username mckinleytabor - UserID 501 GroupID 20 The line in the hdiutil command "-uid $SBUID -gid $SBGID \" is referencing the uid and gid variables set earlier. You can alway type the values manually. Typically if you are creating the sparcebundle for the first user on the system, the uid will be 501 and the gid will be 20. By rerunning the "echo Username $SBUSERNAME - UserID $SBUID GroupID $SBGID " command your uid and gid should be given to you. Replace $SBUID with the UserID and $SBGID with the GroupID.
  4. The purpose of this guide is to show how to create new users WITH "Legacy FileVault" enabled on upgraded or fresh installs of OSX 10.7 Lion. For years, the "solution" given to us by Apple for data security was "FileVault". Starting in OSX 10.3 Panther, users could "encrypt" their home directories. Home directory encryption is better than nothing, but there are still some very real problems. If your system is physically compromised (i.e., taken from you), the opposition will not have access to all the data in your home directory; however they can still make inferences by looking at all the other unencrypted data on your system. Worse yet, if you are foolish enough to use Sleep or Hibernate, it is theoretically possible for a skilled opposition to recover your encryption keys from the unencrypted temporary space on the drive. The REAL solution has been, and always will be, Whole Disk Encryption (WDE) at boot time based on a strong user provided key. This combined with good security practices will render a system almost impervious to any opposition, whether that opposition is a nosy co-worker, professional hacker, or government agency. In an ideal world, the BEST WDE would also offer "plausible deniability". Plausible deniability would render encrypted hard drives that were mathematically and legally indistinguishable from random data and boot from an easily discarded SD card or thumb-drive. Plausible deniability would also allow the user to "boot" into a completely different environment from the one they normally work in which would be hidden within the encrypted disk and indistinguishable. Starting with OSX 10.7 Lion Apple has FINALLY woken up to the concept of WDE, albeit not the ideal kind with plausible deniability. Still, it is better than only home directory encryption, and WAY better than being naked on the battlefield. The new system is just an extension of FileVault, called in some cases "FileVault 2" and in other cases just "FileVault" where the pervious system is call "Legacy FileVault". By design, OSX 10.7 Lion is supposed to be installed as an "Upgrade" to an existing OSX 10.6 Snow Leopard system, however there are several methods for installing OSX 10.7 Lion on a clean hard-drive. In the upgrade situations, if the user had a FileVault encrypted home directory, the encryption system is carried forward into the New OSX 10.7 Lion install and named "Legacy FileVault". It behaves exactly like OSX 10.6 Snow Leopard in every respect. The one area that differs is that new users on the system are unable to activate "Legacy FileVault" for their home directories. Any attempt to use the FileVault format from the Security and Privacy System Preference Plane will result in the user being required to "upgrade" to the new WDE FileVault. Having said that WDE is better than home directory encryption, why does this guide exist? Apple's new WDE FileVault does provide better security than its previous iteration, however that added security comes with a price. WDE FileVault is not 100% compatible with various configurations and installs of Apple Bootcamp software, which allows Mac owners to run multiple operating systems on the same computer. WDE FileVault is also not compatible with users running OSX 10.7 Lion on non-Apple-approved hardware such as being done in the active Hackintosh OSX86 communities. Finally, because there is only 1 encryption key to unlock the disk in WDE, there are situations were multiple users of the same computer need to be blocked from each other with strong encryption, but not share the same encryption key. What you need to have to complete this guide: 1. A fulling working OSX 10.7 Lion system 2. (optional) Access to a OSX 10.6 Snow Leopard system running FileVault. 3. Some method to move files between the two aforementioned computers (thumb drive, network, email, etc) 4. Be semi-comfortable with the Terminal and some UNIX commands 5. An understanding that modern computers have different users and user permissions. 6. About 30 minutes of time. Disclaimer Your data is WAY more important than your hardware. READ THROUGH THIS GUIDE COMPLETELY before trying it. If you are not comfortable or don't understand what is going on, don't do it. If you do this wrong, it could break your computer, burn down your home/office, cause your spouse to leave you, and/or {censored} off Apple. I am in no way responsible for anything you do. Having said THAT, unless you do something REALLY foolish like "sudo rm -rf /" you should be fine. This guide is very benign and messing up the steps would only affect the user you are trying to create and shouldn't spill over into other users or the system. Of course, the best of all words would have you performing this guide on a fresh install of OSX 10.7 Lion on a clean system with no user data, but I guess that's unrealistic for most people. A Note about users This guide can be done on a single user system. However, you might find that it will be easier on some steps to preform the guide logged in as a secondary user NOT as the primary user. Conversely, I strongly recommend that if you are working with a "production" system (i.e. the computer you do "work" from, or your primary home computer) you take the time to setup a second user and try preforming this guide on THAT SECOND USER BEFORE TRYING IT ON THE PRIMARY. One can perform all the steps to the second account while logged into the primary account. I would advise you to log into the second account before following the guide just to make sure the account works. This way if you totally mess up, you are not endangering your primary user account. After you have performed this a couple of times, and feel confident in the procedure, you can then log into the second account and preform the steps on the primary. How to read this guide: Commands that you need to execute will be BOLD Messages back from the system will be in Italics Because this guide deals with the creation of a user, these commands are very specific to the USERNAME and PASSWORD of the user you are trying to create. Apple, like all modern *nix systems, has a "Full Name", "Short Name", and "Password" for each user. My Full Name is McKinley H. Tabor, the Short Name I typically use is mckinleytabor, and my Password is none of your business . In this guide I will use "McKinley H. Tabor", "mckinleytabor", and "mckinleyspassword" in places where that data is needed. You will of-course need to replace these with your own corresponding information, unless of course your name is McKinley Tabor, in which case please contact me! This guide is written for and tested by people who have a working knowledge of computers. There are some high level concepts here, but I will try and break them down into byte-size chunks. In some cases where there is a lack of uniformity and specific instructions are not feasible, I will give high level direction such as "copy files from here to there". In cases where there is uniformity I will give the entire commands in sequence, thus making "copy and paste" easier. While you are NEVER supposed to Copy and Paste commands into the terminal from some strange guy's website, we all do it and I guess I'm as trustworthy as anyone. Step 1: The Chicken and the Egg. NOTE: If you do not have a working OSX 10.6 Snow Leopard computer, it is possible to still create a working Legacy FileVault on OSX 10.7 Lion, however you will LOSE the ability to recover from a forgotten password by using the "Master Password" recovery option. In practice this may not be a big deal for you. If you wish to proceed without the Master Password recovery option, skip to step 3. FileVault on OSX 10.7 Lion requires the system to generate a Certificate and Keychain for it to work. The only means by which you can generate a Certificate and Keychain for FileVault on OSX 10.7 Lion is to enable FileVault. Of course, doing so will encrypt your entire drive, and possibly break BootCamp and most definitely will break your Hackintosh. The trick is to get a Certificate and Keychain into OSX Lion WITHOUT enabling FileVault. As it turns out, FileVault's Certificate and Keychain did not change much between OSX 10.6 Snow Leopard and OSX 10.7 Lion. Therefor it is possible to copy the FileVault Certificate and Keychain from the older system and use it on the newer one. On both systems the FileVault Certificate and Keychain are located in: /Library/Keychains/ You will need to copy two files from this directory on the OSX 10.6 Snow Leopard to the same directory on OSX 10.7 Lion. Of course, if you have not been using FileVault on OSX 10.6 Snow Leopard then these two files WILL NOT BE THERE. The two files are: FileVaultMaster.cer FileVaultMaster.keychain One of these files (FileVaultMaster.cer) is only readable by the "root" user, so you will need to copy them via elevated permission in the terminal. On the OSX 10.6 Snow Leopard system Open Terminal (Hard Drive -> Applications -> Utilities -> Terminal) From the Prompt: sudo cp /Library/Keychains/FileVaultMaster.* ~/Desktop You will be prompted for your password, enter it to continue. You will see your two files now on your desktop. Depending on your configuration, you may may need to run this next command in the Terminal in order to work with the files you just copied. sudo chmod a+rw ~/Desktop/FileVaultMaster.* If prompted for your password, please enter it. At this point you will need to copy these two files from this OSX 10.6 Snow Leopard computer to your new OSX 10.7 Lion computer. You can do this via any method. Place these two files on the desktop of the OSX 10.7 Lion computer. Step 2: Installing the FileVault Certificate and Keychain into OSX 10.7 Lion. On the OSX 10.7 Lion machine open up terminal, we are going to copy the FileVaultMaster files into place and set their permissions properly. sudo cp ~/Desktop/FileVaultMaster.* /Library/Keychains sudo chown root:wheel /Library/Keychains/FileVaultMaster.* sudo chmod 600 /Library/Keychains/FileVaultMaster.cer sudo chmod 644 /Library/Keychains/FileVaultMaster.keychain You have now "installed" the FileVaultMaster files on the OSX 10.7 Lion system. Step 3: Confirm User Information and set Variables Our netx steps will confirm that we are working with the right user and setup some BASH global variables to make life easier for us. These will be SBUSERNAME, SBUID, and SBGID. From here on out these steps umask 077 export SBUSERNAME="mckinleytabor" export SBUID=$(id -u $SBUSERNAME) export SBGID=$(id -g $SBUSERNAME) echo Username $SBUSERNAME - UserID $SBUID GroupID $SBGID If all goes well you should get back something like: Username mckinleytabor - UserID 501 GroupID 20 Note on UserID: Each user on the system as their own UserID number. On OSX 10.7 Lion (an other versions os OSX) the first user of the system, you one you created at install, has a UserID of 501. If you are running this procedure on a second user as a test, that user will have a UserID of 502, 503, 504, etc depending on how many users you have created over time. This guide will work to create a LegacyFileVault for ANY user regardless if it's the first user or the three-hundredth. Because these commands are being done as the "Super User", it will also work to create a LegacyFileVault for the user you have currently logged in. Step 4: Go into the Users Directory In most cases you may be already in the correct directory, but it never hurts to make sure cd /Users/"$SBUSERNAME" pwd The "pwd" command will show the directory you are currently in, if all goes well you should see: /User/mckinleytabor Step 5: Create the sparsebundle These are the commands to generate the encrypted sparsebundle that will be the FileVault. The "sparsebundle" is a type of disk image used by Apple for various things. If you're interested in more information on them, it can be found here: http://en.wikipedia.org/wiki/Sparse_image There are three considerations here: size, password, and the Master Password Recovery. Size. The size of your sparsebudle determines the maximum amount of data you can store in it. The actual size of the sparsebundle on the disk will change based on the data contained within. There have been some discussions about the use of the "autostretch" switch when creating the sparsebundle so as to avoid a maximum data top end. We have not tested the use of autostretch and for the time being recommend you stick with a hard cap, albeit a large one. Pick a size based on the overall capacity of your disk. In a single user computer, it would not hurt to have the sparsebundle be 90% of the total disk capacity. Undersizing the sparsebundle is far more detrimental than oversizing it. The sizes will be noted as Gigabytes so 300g is 300 gigabytes, 1000g is a terabyte. In the examples below I have used "300g" to denote the creation of a three hundred gigabyte sparsebundle. Please change this number to the size that best suits you. One more note about size. If this is new system install, or setting up Legacy FileVault on a new user, there should be no problem with disk size. However, if you are setting up Legacy FileVault for an established user with LOTS of data, the overall disk size might be an issue. During the data "Population" in step 9, you will be doubling the data for the user on the disk for a short time. Therefore, if you have a 300 Gigabyte hard drive, and the user has 200 Gigabytes of data, it will be impossible to do the data population in step 9, because in doing so you will run out of space on the disk. There are two ways around this. First is to create the Legacy FileVault for a new user and move the data over from the old user once you have established that everything is working. Second is to backup the data off the machine to an external source, delete the data off the machine, and then copy it back once Legacy FileVault is working. Password. You MUST use the same password as the one you have for the User you are setting up FileVault for. If these passwords are different, you will get an error when logging in. Master Password Recovery. The Master Password Recovery is based on the transfer of the FileVaultMaster files from steps 1 and 2. Your Master Recovery Password will be different from the password you use for the sparsebundle and will have been set on the OLD OSX 10.6 Snow Leopard Machine. Ergo, you will never be asked to set a master password on this OSX 10.7 Lion. The Master Password is used in two scenarios. First, if you forget your normal password that unlocks the sparsebundle and logs you into the system. Second, if there have been too many bad password attempts. THIS IS IMPORTANT. If you had to skip steps 1 and 2 because you did not have a OSX 10.6 Snow Leopard machine running FileVault so you could copy FileVaultMaster files, you will need to create a sparsebundle without referencing the FileVaultMaster files. This will impair your system only slightly, and it will still work in normal day-to-day operations. Because the sparsebundle creation command is different depending on whether or not you have copied the FileVaultMaster files, I have listed both. In both cases I am still creating a 300g sparsebundle, so edit the command as necessary for your own size. Also the "\" characters allow for a single command to have multiple lines. These characters can be omitted if you are typing them out on a single line. Command if you HAVE the FileVaultMaster files. hdiutil create -size 300g \ -encryption -agentpass \ -certificate /Library/Keychains/FileVaultMaster.cer \ -uid $SBUID -gid $SBGID \ -mode 0700 -fs "HFS+J" -type SPARSEBUNDLE -layout SPUD \ -volname "$SBUSERNAME" "$SBUSERNAME".sparsebundle Command if you DO NOT have the FileVaultMaster files. hdiutil create -size 300g \ -encryption -agentpass \ -uid $SBUID -gid $SBGID \ -mode 0700 -fs "HFS+J" -type SPARSEBUNDLE -layout SPUD \ -volname "$SBUSERNAME" "$SBUSERNAME".sparsebundle (The only difference is the removal of the third line) When asked for a password, USE THE SAME PASSWORD you used when the account was created. If it all works you should get back: created: /Users/mckinleytabor/mckinleytabor.sparsebundle Step 7: Set FileVault Permissions This will set the sparsebundle to have the correct permissions for the user you are creating it for. chown -R "$SBUSERNAME":staff "$SBUSERNAME".sparsebundle Step 8: Mount sparsebundle in a temporary place to check it. Now that the sparsebundle has been created, we will want to mount it up and test it to make sure it works before populating it and attaching it to a user. We will create a temporary directory in the user's home folder and mount the sparsebundle to that directory. This temporary directory will be removed in a later step. mkdir sbdest hdiutil attach -owners on -mountpoint sbdest \ -stdinpass "$SBUSERNAME".sparsebundle You will be prompted for the sparsebundle password and if all goes well you should see something like: /dev/disk2 Apple_partition_scheme /dev/disk2s1 Apple_partition_map /dev/disk2s2 Apple_HFS /Users/mckinleytabor/sbdest Step 9: Populate the sparsebundle This next command will move all the data you need into the sparsebundle for the user to use it as their home directory. It is important, however, before we do the step that you reflect on just how much data you are going to copy. In doing this we will effectively DOUBLE the size on the user's home folder until we can confirm the sparsebundle login and delete all the unencrypted data. If this is LESS than the total size of the disk, then go head with the next command. If it is more STOP NOW and consider making a second user to create the Legacy FileVault for or backing up all of your data off this machine, deleting the data once it has been backed up, then copying it back after we can confirm Legacy FileVault is working. rsync -avxHE ./ sbdest/ \ --exclude="$SBUSERNAME".sparsebundle/ --exclude="sbdest/" This step will take ether a few moments or several hours depending on the size of your data and the speed of your machine. If you followed the directions properly and took time to reflect on the data size, you'll know if you need to wait at the machine, or come back later. There will be lots of messages flying access the screen, these are just telling you what files are being copied. Step 10: Unmount sparsebundle and remove temporary directory After all the data has been moved it's time to unmount our now populated sparsebundle and remove the temporary directory we created in step 8. hdiutil detach sbdest rmdir sbdest Step 11: Modify User's Profile to use sparsebundle Heretofore everything in the guide has been nondestructive from a system standpoint. (unless you have been moving and deleting data to get it to fit in the sparsebundle, in which case God help you) This means that up until now everything that has been done should NOT affect the way our system boots or the way you log into it. At this point, you could stop and simply delete the sparsebundle from the directly in which you created it, and it would be like you never tried doing any of this. These next steps WILL affect how your system logs into a user space, and doing them wrong WILL fubar your user account. We will be be making backups along the way so you can recover. But just remember that from here on out, there be dragons. One last time, please reference my notes above about creating second users and about how I'm not responsible for what you do. Apple keeps profile login information separate from the normal places users go. We are going to dive deep into the directories and alter a user profile to use the sparsebundle as the home folder. First change the directory to the location where user profile data is kept by the system. cd /private/var/db/dslocal/nodes/Default/users/ Next BACKUP the user profile we have been working with just in case you mess up. cp "$SBUSERNAME".plist "$SBUSERNAME".plist.backup Apple stores the user profile information in a binary format, we will need to convert this into text so we can edit it. We will later convert the edited file back into the binary format. sudo plutil -convert xml1 "$SBUSERNAME".plist There is an old civil war about UNIX editors. There are a couple of good ones ones on OSX, but for this we are going to use nano. Edit the file: sudo nano "$SBUSERNAME".plist This file will contain lots of data about the user. Look for the "home" key, it should look like this: <key>home</key> <array> <string>/Users/mckinleytabor</string> </array> You are going to add a couple of lines to the end of this "home" key. In essence you will make it look like: <key>home</key> <array> <string>/Users/mckinleytabor</string> </array> <key>home_loc</key> <array> <string><home_dir><url>file://localhost/Users/mckinleytabor/mckinleytabor.sparsebundle</url></home_dir></string> </array> Under the The "home_loc" and "array" keys, the "string" key is all on one line. Here, like in the rest of the guide, you will need to swap out "mckinleytabor" for the real short name of user you are setting up the Legacy FileVault for. After you have edited the file, you can save the file in nano by Ctrl-O (O as in Oscar), then Ctrl-X to exit. Finally you will need to convert the plist file back to binary format plutil -convert binary1 "$SBUSERNAME".plist If anything goes wrong on the login, you need only to copy the "$SBUSERNAME".plist.backup file back to "$SBUSERNAME".plist overrating edited file. Step 11: (option) Clean up Unused folder in Home Directory This is another Chicken and Egg issue. After populating the sparsebundle, there will be lots of files left over in the unencrypted home folder. You can at this point delete those files, however that is not recommend because you have not, as of yet, established that your sparsebundle login works, and its much more difficult "go back" if all your files are locked up in the sparsebundle and nowhere else. If you are working on a second user however, you can go head and delete everything but sparsebundle folder. The problem comes in when you have "successfully" logged into the user account with the Legacy FileVault. At that point OSX mounts the sparsebundle as the users home folder, obscuring any and all data it once contained. It's still on the disk taking up space, but however you are unable to get access to it logged in as the Legacy FileVault user. The best option for a "post login" clean up is to do the cleaning from the terminal while logged into another account. You will also need to be the "Super User" when doing this because OSX locks away users home folders from each other. Step 12: Login and Enjoy Logout and Log Back in as the Legacy File Vault User. If all went well you should see your Desktop and Documents just as they were. You might have a warm feeling around your backside knowing that your ass is covered should someone take your system. Enjoy that feeling along with the power and the civil liberties encryption gives us all. Step 13: After-thoughts You may get a message about "Updating" to the new FileVault. You will of course NOT want to do this. Just click no, and go about your business. A good way to test your Legacy FileVault is to open the System Preferences and look under Security & Privacy. You should now see "Legacy FileVault". If you did not have access to a OSX 10.6 Snow Leopard system and had to skip steps 1 and 2, there will be an option to Set a Master Password in this Legacy FileVault tab. However because the sparsebundle you created did not reference this, setting a Master Password will have no effect your system. Encryption is sort of a religious requirement in my line of work. But encryption alone is not good enough to protect you. You need to combine strong encryption with good security procedures in order to maximize your protection. I would encourage you to take the time to read up on how to protect your data and your identity. Acknowledgements : The idea and some of the sequencing for this article came from Fabio Maione. <http://lab.maiux.com/en/os-x/criptare-la-home-directory-di-un-utente-usando-legacy-filevault-in-os-x-lion> A "Living" version of the document can be found on my website at: http://www.taborcg.com
  5. Legacy FileVault on OSX 10.7 Lion

    Well I figured this out. It has NOTHING to do with FileVault. We had thought FileVault was the curperate due to these programs working on a new install install of Lion, but stopped working after we implemented our "Legacy File Vault" option. It is most likely a library permission issue, related to users who are NOT the first user on the system. In creating our Legacy File Vaults, we create it on a second user just in case the procedure fails. These second users have the problems I describe above even if FileVault is not active. I'm not sure "why" this is happening just yet.
  6. Legacy FileVault on OSX 10.7 Lion

    I have recently installed Lion on a Dell Optiplex 745. After some hacking, everything works including access to the AppStore. Our office actually operates completely off half a dozen Dell Optiplex gx620s running Snow Leopard. This Optiplex 745 is our first foray into Lion. In our world, data encryption is a religious requirement. This means that all our home directories are locked up with FileVault on Snow Leopard, and we use Truecrypt for external drives, thumb drives, etc. We all know that FileVault has undergone a MASSIVE change in Lion. It's moved from being a home directory encryption system, to be a full all Whole Disk Encryption (WDE) system. Of course WDE is pretty much the holly grail of physical data security, and we're very happy that Apple has gone in this direction Sadly however this move has caused us the the Hackintosh Community some issue. While FileVault's new WDE is superior to home directory encryption, the new system is complete incompatible with current technology Hackintoshes. Lion does however support "Legacy FileVault" which operates exactly the same way as it did in Snow Leopard. The one exception being that in Lion you cannot create new "Legacy FileVault" home directory encrypted sparsebundels via the Security and Privacy System Preference. I'm guess that Apple allows these "Legacy FileVault" sparsebundels because Lion was intended to be installed as an "in-place" upgrade to Snow Leopard and there had to be some mechanism in Lion to account for user upgrading who had FileVault turned on. For Hackintosh however, because we almost universally do "clean" installs for the OS rather than upgrading, there is no method to activate "Legacy FileVault" via the GUI after an install. Well...... I spent the better part of a day creating a method by which Lion Hackintosh Users can create NEW users with "Legacy FileVault" sparsebundels. The methodology is sound, and I am very eager to publish my guide. There is however a small and bizarre, issue and I'm looking for some help from the community. The operation of creating New "Legacy FileVault" Users in Lion hinges on having the System's FileVault Certificate and Keychain. These are created when FileVault is activated and stored as two files (FileVaultMaster.cer and FileVaultMaster.keychain) in /Library/Keychains. For Hackintosh Lion this presents a Chicken and Egg Problem, to get the system to generate these files, a user must run the FileVault WDE process, which damages the system. As a work around, I copied these two files from a working Snow Leopard system running FileVault. Using these files I was able to create and use "Legacy FileVault". (once I have this bug worked out I'll publish the step by step on how to do it.) The small and bizarre "bug" is that when I log into my newly created "Legacy FileVault" user, some (not all) of my Applications stop working. I've tracked the issue down to what I feel is a 32bit vs 64bit problem. So far the the applications we identified that are effected are Truecrypt 7.1 and SecureCRT (terminal emulator). Truecrypt crashes on launch unable to load a library, while SecureCRT gives the slashed/circle icon indicating that it cannot run. I want to stress that BOTH of these programs work perfectly on non-"Legacy FileVault" accounts, and they are being run from the same location (the Application folder). So the problem is obviously linked to "Legacy FileVault". I'm thinking that maybe because I used FileVaultMaster.cer from a 32bit Snow Leopard system in signing the sparsebundel to create the Legacy FileVault user that perhaps it's having some adverse effect on the 64 bit lion. But that doesn't really make sense. I am hoping that some kind person that has access to a REAL Mac running FileVault WDE would be willing to send me a copy of his or her FileVaultMaster.cer and FileVaultMaster.keychain files so that I can test if it is the Cet that's causing the problem. There is also the possibility that this is a genuine Apple bug related to "Legacy FileVault", and has nothing to do with my Hackintoshery. Of course the only way to test that would be to have someone with a Real Mac and "Legacy FileVault" running install and test TrueCrypt 7.1. If anyone has any input on this topic, I would be most interested.
  7. Success!! I managed to get my gx520 to 10.5.6. Here is a general outline of what I did. First, I followed all the directions here to get my system to 10.5.5 with the Voodoo Kernel. Video, Audio (which was never an issue), and USB all worked. Used the system in a semi production environment for 6 weeks without any problems. I did non-system updates via "Software Update" without issue. Installed all my software without issue. I downloaded the "Normal" 10.5.6 update from Apple (NOT the combo update). http://support.apple.com/downloads/Mac_OS_X_10_5_6_Update Next, I opened terminal and did the little script trick to kill AppleIntelCPUPowerManagement.kext aborning, as mentioned above when doing the other oupdates. It's best to just become root for these terminal commands: "sudo -s" then password when asked. “while sleep 1 ; do rm -rf /System/Library/Extensions/AppleIntelCPUPowerManagement.kext ; done” While the little do/while loop ran in the background, I opened and installed Mac_OS_X_10_5_6_Update. as always: DO NOT RESTART when asked Back in the terminal, I stop the script (control-c), and did a quick check to make sure AppleIntelCPUPowerManagement.kext was not there. "ls -l /System/Library/Extensions/AppleIntelCPUPowerManagement*" On my system, there was a directory AppleIntelCPUPowerManagement.kext.org with the original kext in it. But as long as AppleIntelCPUPowerManagement.kext is not in /System/Library/Extensions/ you're good to go. Next, you'll need to check the file /System/InstallAtStartup/scripts/1 I use "vi" to edit text files in the console, so at the terminal type "vi /System/InstallAtStartup/scripts/1" ("nano /System/InstallAtStartup/scripts/1" also works if you like editor better) Look for any lines that say something to the effect of "Dont Steal Mac OSX.kext". I had read that there MIGHT be lines in this file to that effect. On my system, there were no lines that said anything like that. If there are lines like that in your /System/InstallAtStartup/scripts/1 file, I read that you should replace "Dont Steal Mac OSX.kext" with "dsmos.kext". Seince I did not have any of the offentding lines, I cannot commit as to this edit. For me, I just left /System/InstallAtStartup/scripts/1 alone. Finally, I ran "diskutil repairpermissions /" waited on baited breath when it always hangs at 20%, when finished, then I do it again just because I'm OCD. Now you can reboot. I used the -v option when rebooting to see all the text that was to fast for me to read. Don't panic, the system WILL reboot a couple of times before it's done. Once the system was back up, I noticed that the screen resolution was off. So I did the trick of reinstalling just the AppleIntelIntegratedFramebuffer.kext as previously stated in "Quick Fix on Intel GMA 950 Video Card" Reboot, screen res was fixed. Now, comes the hard part...... My USB auto-mounting was not working. I have to admit that the USB auto-mount did not work after my 10.5.5 install despite having done the steps in: "Fixing USB auto mount". Now I FIX my usb auto-mounting in 10.5.5, but because I can be a selfish {censored} sometime, I completely forgot to document and share how I did it. So now after the update to 10.5.6, my USB auto-mount failed again. This time, I messed with it for about 30 minuets, and got is working. But here's the catch, I'm not sure which of the things I tried got it working. I know the things I did, and the oder in which I did them, but I am unsure if it was the "LAST" thing I did that fixed it, or if the last things I did built upon something I had done before. I suspect the the problem was a mismatch between my Kernel version "uname -a" which gave me: Darwin Kernel Version 9.5.0: Sat Dec 6 19:39:54 IST 2008; Voodoo; and the Kernel setting in my /S/L/E/system.kext/Info.plist which was reading 9.2.0 I tried the fix from "Quick Fix on Intel GMA 950 Video Card" -- did not work I then tried using "usb fix 1.3.mpkg" which I found at: http://www.insanelymac.com/forum/index.php?showtopic=95789 -- I think his is what fixed me last time. But Kernel 9.5 is not an option in this install of "usb fix 1.3.mpkg" and the Kernel 9.2.2 did not work either.... I then googled around and found: http://www.insanelymac.com/forum/index.php?showtopic=117029 and did those steps, but no love there ether... What got me working was this. I just Google 9.5.0 system.kext and found: http://www.infinitemac.com/f39/voodoo-xnu-...-testing-t1361/ which gave me: http://rogue.infinitemac.com/files/950_System_kext.zip I used Kext Helper b7 to install it, and even before the restart, my USB Key popped up. After the restart all still worked. In the end I'm not sure if just putting the 950_System_kext.zip file in place fixed it, or if it needed something else I had done before that.. so your milage may very.
  8. Greetings and Salutations.. Having followed all the directions, I now have a Dell Optiplex gx520 running 10.5.5. The setup is quite nice, and with 4GB of ram it scores quite well on the xbench. My question is however, has anyone taken the plunge with 10.5.6 on this hardware platform. http://support.apple.com/downloads/Mac_OS_...-6_Combo_Update I don't mind taking one for the team, in fact I'm backing up a disk image as we speak, but I was hoping for some words of encouragement. If not, then I can pioneer it and report back my findings. Ciao