After I set file permission to 0600 on /etc/passwd, my linux vm failed to boot [duplicate]

The permissions of /etc/shadow are 600, which means it is not readable for anyone except root.

However, as all passwords inside it are not stored in clear text but as hashes (which means it is impossible to compute the original password from the hash), why may it not be read by everyone?

Solution 1:

To prevent offline brute-force attacks.

Even though you can't reverse a hash, you can still try hashing every possible password until you find a match, and you can do millions of tries per second with good hardware and local access to the file.

If the file had 644 permissions, then anyone who logged in to your system, even in a guest session, would be able to copy this file off of your computer (whether to a USB stick or remotely via scp) and attempt an offline brute-force attack, without leaving any evidence of this on your computer.

Note that the permissions on Ubuntu are actually 640, not 600:

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1239 Jun 25 04:35 /etc/shadow

This doesn't matter much though, since there are still no permissions for others, and, by default, no one is in the shadow group.

Originally, hashes were stored in /etc/passwd (which is why it's called passwd), as back when Linux was created, cracking a hash, even the weak types used back then, was practically impossible. Eventually, though, processing power advanced to the point where cracking a hash, at least of a relatively weak password, became feasible.

Changing the permissions of /etc/passwd to 640 or 600 wouldn't work, as there are many legitimate reasons to be able to read /etc/passwd as a normal user (converting UIDs to usernames, getting a user's full name, phone number, etc), so hashes were moved to /etc/shadow, which was given 640 permissions. An x in place of the password hash field for a user in /etc/passwd is used to indicate that the hash for that user is stored in /etc/shadow instead.

Solution 2:

Actually, /etc/shadow was created to allow moving away from a publicly readable list of user names and passwords.

Hang in there, this will be a little bit of a history lesson, before we get to the actual answer. If you don't care about history, just scroll down a bit.

In the old days, Unix-like OSes, including Linux, generally all kept the passwords in /etc/passwd. That file was world readable, and still is, because it contains information allowing mapping for example between numeric user IDs and user names. That information is highly useful even to ordinary users for perfectly legitimate purposes, so having the file world readable was of great benefit to usability.

Even back then, people realized that having the passwords in plain text in a file in a well-known location that anyone who could log in could read freely was a bad idea. So passwords were hashed, in a sense. That's the old "crypt" password hashing mechanism, which is almost never used on modern systems, but often supported for legacy purposes.

Take a look at /etc/passwd on your system. See that second field, which says x everywhere? It used to hold the hashed password for the account in question.

The problem was that people could download /etc/passwd, or even not download it, and work on cracking the passwords. This wasn't a big problem while computers weren't particularly powerful (Clifford Stoll, in The Cuckoo's Egg, gives, as I recall, the time to hash one password on an IBM PC class system in the mid-1980s as about a second), but it became a problem as processing power increased. At some point, with a decent word list, cracking those passwords became too easy. For technical reasons, this scheme also couldn't support passwords longer than eight bytes.

Two things were done to solve this:

• Moving to stronger hash functions. The old crypt() had outlived its useful life, and more modern schemes were devised that were both future-proofed and computationally stronger.
• Move the hashed passwords into a file that wasn't readable by just anyone. This way, even if a password hash function turned out to be weaker than expected, or if someone had a weak password to begin with, there was another obstacle for an attacker to gain access to the hash values to begin with. It was no longer free-for-all.

That file is /etc/shadow.

The software that works with /etc/shadow is generally very small, highly focused, and tends to receive some extra scrutiny in reviews because of the potential for problems. It also runs with special permissions, which allows it to read and modify /etc/shadow, while keeping ordinary users unable to look at that file.

So there you have it: The permissions on /etc/shadow are restrictive (though, as pointed out already, not quite as restrictive as you state) because the whole purpose of that file is to restrict access to sensitive data.

A password hash is supposed to be strong, but if your password is on the Top 500 Passwords on the Internet lists, anyone with access to the hash will still be able to find the password quickly. Protecting the hash prevents that simple attack and raises the bar for a successful attack from simple peeking to requiring one to either be a system administrator on the host already, or go through a privilege escalation attack first. Especially on a correctly administered multi-user system, both of those are significantly more difficult than just looking at a world-readable file.

Solution 3:

Why permission for /etc/shadow file is set to be 600?

Who told you that?

$ls -l /etc/shadow
-rw-r----- 1 root shadow 1407 mei 18 10:05 /etc/shadow

• it is 640.

Simple answer: permissions in Linux are taken serious. There is no reason for "others" to do anything with /etc/shadow. And there is no reason for group "shadow" to write to it. And execution is out of the order.

However, as all passwords inside it are not stored in clear text but as hashes (which means it is impossible to compute the original password from the hash), why may it not be read by everyone?

Because there is not a single reason to do so.

Hashes are one-way. Giving someone read access makes it possible for him to use a script to abuse this one-way: just list any word you can imagine and create the hash. At some point it might match the password. Might take a while though too.

This answer is interesting and has some estimates on brute forcing.

Solution 4:

Important background: /etc/shadow exists solely for the purpose of keeping the password hashes hidden. In ye Early Days of Unix, password hashes were stored in /etc/passwd. As computers got more powerful, network connections more persistent and security exploits more sophisticated, people realized that keeping password hashes word-readable was asking for trouble. (I won't detail the exploits; there's enough good answers about that already.)

But /etc/passwd couldn't be read-protected: It is used by all sorts of programs to map numeric user ids to usernames, and to look up home directories, default shells, the user's full name (and office number etc. -- check out man finger). So the sensitive part, the password hashes, was moved to /etc/shadow, and the rest remained as it was. That's why /etc/passwd, despide the name, contains everything except the (hashed) password.