Why is root security enforced but $HOME typically unprotected?

I'm going to disagree with the answers that say the age of the Unix security model or the environment in which it was developed are at fault. I don't think that's the case because there are mechanisms in place to handle this.

The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data.

The superuser's permissions exist to protect the system from its users. The permissions on user accounts are there to protect the account from other non-root accounts.

By executing a program, you give it permissions to do things with your UID. Since your UID has full access to your home directory, you've transitively given the program the same access. Just as the superuser has the access to make changes to the system files that need protection from malicious behavior (passwords, configuration, binaries), you may have data in your home directory that needs the same kind of protection.

The principle of least privilege says that you shouldn't give any more access than is absolutely necessary. The decision process for running any program should be the same with respect to your files as it is to system files. If you wouldn't give a piece of code you don't trust unrestricted use of the superuser account in the interest of protecting the system, it shouldn't be given unrestricted use of your account in the interest of protecting your data.

Is there no way to prevent malicious code happening in $HOME? And why does nobody care about it?

Unix doesn't offer permissions that granular for the same reason there isn't a blade guard around the rm command: the permissions aren't there to protect users from themselves.

The way to prevent malicious code from damaging files in your home directory is to not run it using your account. Create a separate user that doesn't have any special permissions and run code under that UID until you've determined whether or not you can trust it.

There are other ways to do this, such as chrooted jails, but setting those up takes more work, and escaping them is no longer the challenge it once was.

Because the UNIX-based security model is 50 years old.

UNIX underlies most widespread OSs, and even the big exception Windows has been influenced by it more than is apparent. It stems from a time when computers were big, expensive, slow machines exclusively used by arcane specialists.

At that time, users simply didn't have extensive personal data collections on any computer, not their university server, not their personal computer (and certainly not their mobile phone). The data that varied from user to user were typically input and output data of scientific computing processes - losing them might constitute a loss, but largely one that could be compensated by re-computing them, certainly nothing like the consequences of today's data leaks.

Nobody would have had their diary, banking information or nude pictures on a computer, so protecting them from malicious access wasn't something that had a high priority - in fact, most undergraduates in the 70s would probably have been thrilled if others showed an interest in their research data. Therefore, preventing data loss was considered the top priority in computer security, and that is adequately ensured by regular back-ups rather than access control.

This is a highly astute observation. Yes, malware running as your user can damage/destroy/modify data in your home directory. Yes, user separation on single user systems is less useful than on servers. However, there are still some things only the root user (or equivalent) can do:

• Install a rootkit in the kernel.
• Modify the bootloader to contain an early backdoor for persistence.
• Erase all blocks of the hard disk, rendering your data irretrievable.

Honestly, I find the privilege separation on workstations most useful to protect the workstation from it's biggest enemy: me. It makes it harder to screw up and break my system.

Additionally, you could always set up a cron job as root that makes a backup of your home directory (with, e.g., rsnapshot) and stores it such that it's not writable by your user. That would be some level of protection in the situation you describe.

Obligatory xkcd