[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Ok, let's answer all of these in one go: >> How do you use dd to backup and restore the MBR? To backup, you do the following: dd if=/dev/sda of=/path/to/backup/mbr.bak bs=512 count=1 This can be done from your running linux install - obviously, change sda if your boot disk is different and provide your own path and filename to backup to. You should backup the MBR to an external medium such as a USB stick ideally or via SSH to another host. If your MBR is trashed for any reason, you will need to boot your system from a live CD/USB/PXE or whatever you prefer - as long as you have "dd" and access to your backup file anything will do. As others have said, Ultimate Boot CD is very good, as is System Rescue CD, Backtrack, a spare Ubuntu installer - anything you're comfortable with. You then simply reverse the process: dd if=/path/to/backup/mbr.bak of=/dev/sda bs=512 count=1 It's important to note this is only the 512 byte MBR you're restoring, if you've trashed Grub or the windows loader you'll still have to separately repair them. >> Actually, I'd like to know why it's considered such a good idea (full disk vs home directory). I really thought this was obvious, but fair enough: total* vs partial security. In the enterprise sector, it's necessary for regulatory compliance. Any portable device that contains corporate data, particularly patient/customer data *must* be fully encrypted. It's not enough to just tell your MacBook to use FileVault to lock your home directory, or your Ubuntu installer to only encrypt your home directory: everything has to be locked up tight. For home users, you may be thinking it's overkill: it's not. If you've already realised that encrypting your home directory is desirable, why would you stop there and leave the entire rest of the system vulnerable? It just doesn't make sense. Surely you realise that on a linux system, there is a *lot* of interesting data outside of /home: just for a start, /etc is full of stuff like password hashes and /var/log is ripe for plundering. Imagine your laptop with only /home encrypted is lost or stolen, and not just to a random crack junkie who'll flog it for £30. Imagine I stole it, for example, or just got my hands on it for 30 minutes whilst you were off to lunch. I'll boot the system from a live medium, swipe your hashes for cracking (or just zero them out) which is a very quick job on GPGPUs or one of many cloud services. I now have root and if I crack your password, I can now log in as you (probably with sudo as well). /home only encryption on linux doesn't require a separate password to login and unlock the crypto - once I have your password, I'm in. Full disk encryption requires a separate password early in the initial boot process and is much harder to defeat. See https://help.ubuntu.com/community/EncryptedHome for more dire warnings about how not having an encrypted swap partition is a bad idea (there are many tools such as metasploit and canvas I can use to extract compromising details from swap). Of course, once I'm in, you're screwed: I'll install my APT (advanced persistent threat), doctor your logs and put your laptop back where I found it, except it's now my laptop rather than yours. Sound far fetched? It's not: I've done this (legally in my capacity as sysadmin/security guy!) many times. Hopefully you don't have any highly skilled enemies, and your laptop probably isn't a business laptop with regulatory control issues or $$$ worth of company secrets or the CIA asset list on it but if you're already actually thinking about using encryption at all, why stop part way and do a half-arsed job of it? Unless your laptop is the oldest piece of crap in the world, the performance hit is negligible (perhaps 1-2% on heavy I/O). Even Apple have now extended FileVault to full system vs home only and even to TimeMachine backups. *total: Final note - even this can be compromised with local access. As someone else noted, even with full encryption, there is a small unencrypted /boot partition as you have to at least initialize the kernel/ramdisk to even get to the passphrase, obviously. In this case, I grab your laptop, offline boot and replace your kernel with my own malicious version. It's identical to yours, except it has a keylogger. Game over. Amusingly, although it introduces all kinds of other problems, Microsoft's new signed bootloader/secure boot initiative actually fixes this hole. Except with local access, once again I boot the laptop, disable it in UEFI (unlike ARM systems, secure boot PCs will have a UEFI option to disable it), proceed as usual. The old adage still holds: with physical access, you're doomed. Hope that clears that up for you. Cheers -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq