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…
