MacOS – Mac OSX : How to password protect an .app or other folder from deleting/moving by user/admin/root

Disclaimer

This answer is not intended as security advice for regular users. Setting your Mac's securelevel to 1 could potentially cause certain software or hardware drivers to malfunction, so I advise doing your own due diligence and independent research and testing to determine whether there could be any undesirable consequences to performing these steps.

Section 5.4.2 of the below-linked article about BSD's features related to security restrictions on the super-user is a good place to start. http://docstore.mik.ua/orelly/other/puis3rd/0596003234_puis3-chp-5-sect-4.html

In case that link breaks in the future, the most important section of the article lists the effects of setting kern.securelevel=1:

Write access to the raw disk partitions is prohibited. (This forces all changes to the disk to go through the filesystem.)

Raw access to the SCSI bus controller is prohibited.

Files that have the immutable flag set cannot be changed. Files that have the append-only bit set can only be appended to, and not otherwise modified or deleted.

The contents of IP packets cannot be logged.

Raw I/O to the system console is prohibited.

Raw writes to system memory or I/O device controllers from user programs are prohibited.

Some access is denied to the Linux /proc filesystem.

Additional kernel modules cannot be loaded.

The system clock cannot be set backwards. In addition, it cannot be set forward more than a maximum of one second, and it can be set forward only once per second (effectively, the clock can be pushed at most to double time).

This list is not comprehensive.

TLDR: setting kern.securelevel=1 could have more consequences than what's described in the below steps. Be careful.

That said, I have tested out these steps on a regular iMac with OS X 10.10.2 and did not notice any problems as a result. In the past, securelevel 1 was the default setting for OS X, and manpages in OS X 10.10 still indirectly indicate that 1 is the default setting (they say you must reboot in single user mode to remove schg, which requires securelevel 0).

However, in reality, securelevel 0 has been the default setting since OS X 10.5. When the online community learned that Apple quietly changed the default to 0, some sysadmins on Apple Discussions threads called it "unconscionable" of Apple to do this. I've also found some security guides online that say setting kern.securelevel=1 is an important step to take for securing your Mac. YMMV.

Answer Summary

As long as you set a firmware password on a Mac, you can make any file on that Mac unable to be deleted by anyone, just by using this simple Terminal command:

sudo chflags schg /path/to/file

Next make sure your Mac will always boot to securelevel 1 by doing:

sudo vi /etc/sysctl.conf

Once in vi editor, type i to enter insert mode, then type kern.securelevel=1. Next hit enter, then colon, then type wq and hit enter.

Lastly in Terminal type:

sudo chflags schg /etc/sysctl.conf
sudo sysctl kern.securelevel=1

Now that securelevel is 1 and the schg flag is set, the file cannot be deleted unless the system is rebooted into single user mode.

If a firmware password has been set, you need that password to get into single user mode. Further you need it to get into target disk mode or change the startup disk.

With the schg flag set, even root cannot delete the file. Nobody can modify it from the Finder or Terminal. It will appear locked in the Finder, but the locked checkbox will always remain grayed out, no matter what, even with an admin password. In the Terminal, sudo rm /path/to/file will now fail, saying "Operation not permitted". Also, sudo SetFile -a l /path/to/file will fail with, "ERROR: Unexpected error. (-5000)". :D

To delete this file, someone will need to use the firmware password to reboot into single user mode, then unset the schg flag using this command:

sudo chflags noschg /path/to/file

After that it can be deleted.

UPDATE: Critical Extra Steps Necessary for Answer to Work

Update added Wed. 18 Mar. 2015 ~1:20 PM PDT: it came to my attention in the comments to this answer that someone with sudo access on the system could delete the protected file by renaming the /private/etc directory, then copying all its contents except the sysctl.conf file into a new /private/etc directory, and restarting. This would cause secure level to revert to zero.

To prevent this, after performing the above steps, you should also perform the following commands:

sudo chflags schg /private
sudo chflags -h schg /etc

The first command makes the /private directory and its subdirectories unable to be renamed. The second command makes the root-level symbolic link to /private/etc impossible to rename or delete. (The -h argument makes chflags act upon the symbolic link itself, instead of acting on the target of the symbolic link.)

Main Caveats

1. If you're on a Hackintosh or Mac Pro with an unofficial PC graphics card that has not been flashed with official Apple firmware or something functionally identical to that, this trick won't work. I am not sure if they can boot to single user mode, so if you establish the sysctl.conf file, and set it to schg, it may be like that forever. Which means any files set to schg can never be deleted.

2. There may be some physical ways to reset the firmware password by removing RAM or delete the file by removing the SSD/HDD and attaching to another computer.

Explanation of Answer

To set a firmware password for your Mac using the steps shown when you google, "how to set a firmware password on a mac". Briefly the steps are:

• Reboot in recovery mode

• Select Firmware Password Utility from the Utilities menu and set the password

• ...

• PROFIT!

Explanation of Caveats

Note that on Macs with removable RAM, a hacker may be able to reset your firmware password by changing the amount of RAM, then clearing your PRAM a bunch of times. So on Macs like that, take appropriate physical security measures to prevent manual access to the computer's internal components.

Suffice it to say you must get to securelevel 0 for chflags noschg to work, and normally the only way to get back to securelevel 0 is to reboot in single user mode. Again this might be impossible if your Mac lacks Apple firmware. If you're paranoid/unsure, can see your current securelevel by typing sysctl kern.securelevel in Terminal; it should always be 1 after the steps have been followed unless you're in single user mode!

Further notes

As far as I know, and correct me if I'm wrong, but the only way around a firmware password (other than resetting it through the RAM removal trick) is to remove the primary hard disk or SSD from the computer in question, and access it from another computer using a SATA to USB adapter, or something similar. (Government agencies and/or Apple might have a secret, classified backdoor... but if they're after you, then you probably want to delete files, not prevent their deletion :D.)

So, technically speaking, setting schg only really solves your problem with 100% infallibility if you're on one if the newer Macs without replaceable RAM and without a replaceable hard drive (i.e. a Retina MacBook Pro, MacBook Air, etc.) and you set your EFI password, because those are the only Macs without removable RAM or a removeable SSD. (Of course if someone takes out your drive just to delete a file, again, you probably have worse problems, like, dude where's my hard drive?)

The 21.5" iMac's lack of "user-replaceable" RAM makes it a lot harder to circumvent the EFI password and steal RAM, which is probably why Apple made it that way, as it's intended heavily for use in schools where kids can and will circumvent any security measures :D (I know because in my day we used to hack right past AtEase on System 7 to play Marathon...)

On non-21.5" iMacs you can prevent the RAM-removal/firmware-password-reset trick by investing $40-50 in a Maclocks-brand lock for iMac. It goes into the security port and has a metal plate that covers up the power socket where the release for the RAM hatch is. With that physical lock in place, someone would need a diamond saw or similar to delete your schg-protected file... and if people are taking diamond saws to your computers then you have a lot worse problems to worry about than a file getting deleted, like, dude, where's my computer?