0

Context:

I use a mac for data recovery forensic operations, and for compliance with my users' requirements, I need to guarantee that no disk writes will be performed on a physical hard disk attached to a mac until a user enables the disk.

Question:

Is it possible to disable all access to a disk, SATA port, or disk controller entirely outside of the OS, before the system boots?

Disabling only read access is acceptable, but tends to be harder to verify compared to "make the computer act like the disk itself isn't plugged in".

When we were doing data recovery with a Linux homemade tower, we would go into the BIOS and disable the SATA port with the sensitive disks on it.

It's OK to disable the entire disk controller as part of a solution; these systems are externally booted from USB devices, and internal hard disks will not be used until they are re-enabled.

The physical port to which the disks in question are connected will not change.

What I've Tried:

I've seen the solutions to this question. Those solutions all disable disks right after boot, which is not sufficient: disabling automount of the disk or hiding it from OSX's disk management does not satisfy the users' (admittedly silly) audit requirements.

Other Ideas:

Is it possible to do this from an EFI shell? I'm happy to install rEFInd or similar on the bootable USBs.

Are there nvram settings that can be changed to achieve this?

Are there kernel boot parameters that instruct OSX not to initialize or use a PCI device, tree, or disk?

Are there kernel modules that I could install that would achieve this? If so, they'd probably need to be open source so the users could audit them and make sure they're loaded early enough to not let any writes through.

Since the recovery OS is USB, are there kexts that I could uninstall in order to disable access to all disks/SATA devices?

  • What OS is on the USB that you want to boot from a Mac? – user3439894 Nov 3 '16 at 18:36
  • OSX; it's just a recovery version that we run our forensic tool from. – Zac B Nov 3 '16 at 21:03
1

A simple solution since you are booting off a USB/Recovery disk, you could mount the drive in "read only" via diskutil:

diskutil mountDisk readOnly /dev/diskX

Now, if your USB/Recovery disk has already mounted it when it loads, you will have to unmount it first:

diskutil unmountDisk /dev/diskX

diskX is the drive identifier of the disk you are attempting to (un)mount. You can find it by issuing the command diskutil list and finding the drive you are interested in.

From the manpage:

Mount a single volume. If readOnly is specified, then the file system is mounted read-only, even if the volume's underlying file system and/or device and/or media supports writing; even the super-user may not write to it; this is the same as the rdonly option to mount (8). If a -mountPoint is specified, then that path, rather than the standard path of /Volumes/VolumeName, will be used as the view into the volume file content; a directory at that path must already exist.

| improve this answer | |
  • That would indeed work for making a volume read-only after the recovery system started. However, the volumes are automatically mounted (and probed, and may have their filesystems' mount bits checked/get fscked/have other things talk to them) before I get into userland where I can unmount and then remount-as-read-only the disk. The /etc/fstab mount-blocker is a bit closer to "never ever touch this disk, even while booting", but we proposed that to the client and it was still deemed insufficient write prevention. They want everything but a hardware write blocker, basically. – Zac B Nov 7 '16 at 13:01
  • You may have to make a clone image by mounting it as readonly from a USB connection (use dd) then work with that image on your local machine. To validate if the clone and the original, you can compare the hash or checksums - there are tools available for you to do this. – Allan Nov 7 '16 at 13:12
  • 1
    @Zac B, You said "They want everything but a hardware write blocker, basically.", so what exactly do they want? This would be much easier if the target HDD/SSD could be placed in a external case and plugged into a already running system and use Disk Arbitrator to ensure it mounts Read-Only. Otherwise boot the system from a Linux Live USB that does not automatically mount and HFS+ volume and make a dd image. – user3439894 Nov 7 '16 at 13:50
  • They want a reasonably provable/auditable thing that prevents OSX from seeing or registering the existence of a connected disk at all, from as early as possible in the boot process; preferably from EFI handoff. We do ship some systems with disconnected disks, and sometimes use hardware write blockers. But, in the case of OSX laptops, this won't work: users can't disassemble the machine and plug in the disk. The second annoyance is that the forensic analysis tool (proprietary) is written only for OSX, so a Linux live USB, while much easier for preventing disk access, is not an option. – Zac B Nov 7 '16 at 20:11
  • We've also researched shipping Linux live USBs that autostart a virtual machine running OSX, and conditionally connect the disks to the VM guest. However, this proved a) very slow, especially over USB, and b) unstable/prone to failures. – Zac B Nov 7 '16 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .