# Is /etc/shadow safe?

## grant123

I'm syncing my laptop with several other identical laptops which are used by other people.  Are my own passwords in /etc/shadow safe?

----------

## SirRobin2318

/etc/shadow is fine, the hashed passwords are in /etc/passwd-. (not a typo, with a dash at the end).

----------

## grant123

My hashed passwords appear to be in /etc/shadow and not /etc/passwd-.  Either way, is the file containing them safe to distribute?

----------

## SirRobin2318

How did you manage that? Did you purposefully specify that? What is the ownership of that file? Your system may be insecure to begin with...

In any case, no, I wouldn't; http://www.openwall.com/john/doc/EXAMPLES.shtml

----------

## grant123

I definitely did not do it on purpose, but it's like that on all of my systems so Gentoo must set it up that way:

-rw-r----- 1 root root 1158 Feb 26 09:55 /etc/shadow

Your link isn't working right now, but is the idea that someone could decipher the password if they have access to its hash?

Are there other files I should not distribute from a security or privacy perspective besides those in /home?

----------

## SirRobin2318

Actually, you are right. shadow and shadow- are the same files on my system too... I'll look into that.

But yeah, giving the expected hash to an attacker enables him to brute force the system too easily. 

How are you syncing the pcs? just a cp/tar/dd? Same hardware? 

To ensure no important info would leak out, I'd take the opposite approach: copy your world file after having done the basic install, emerge @world, then choose important /etc files to copy.

----------

## SirRobin2318

OK, so the - version of /etc's group, shadow, passwd files are just backups, I was mistaken there.

----------

## grant123

 *Quote:*   

> But yeah, giving the expected hash to an attacker enables him to brute force the system too easily.

 

Maybe I could counteract that by using really good passwords.

I'm syncing with rsync.  Identical hardware.  I'm really happy with the way it works, I just want to be careful of any stray files that shouldn't be distributed.  Any others come to mind outside of /home?

----------

## Hu

Anything in /etc needs to be given special consideration before syncing.  As you know, some files in /etc are security-sensitive.  Others may represent system-specific configuration, such as preference on which services to start, how to configure the network, and so on.  Identical hardware does not guarantee identical software usage, so even if the files can be shared, that may not be the right choice.

----------

## szatox

Why you're syncing those laptops?

If you want to save some compilation time, you can use portage to build binary packages and then install them (with portage)  on the rest.

----------

## SirRobin2318

If your concern is build time, look into this instead: https://wiki.gentoo.org/wiki/Binary_package_guide#Creating_binary_packages

As for etc configuration, I keep the files that are modified in a git, and sync that with other PC's etc. I do it with files like /etc/portage, X11. 

I'm the user of both those PCs, so I also have sudo, sshd, polkit & firewall rules. Be careful before sharing those, there could be sensitive information in them (mainly if they're badly configured).

----------

## 666threesixes666

http://www.linuxsolutions.fr/annvix-using-the-tcb-shadow-alternative/

http://www.openwall.com/tcb/

i remember seeing something about shadow being compromised a while ago.

http://felinemenace.org/~andrewg/configuring_gentoo_to_use_openwall_tcb/

brew me up a wiki so i can sleep and get drunk instead of fixing it myself.

----------

## grant123

 *Quote:*   

> Anything in /etc needs to be given special consideration before syncing. As you know, some files in /etc are security-sensitive.

 

Which are potentially security-sensitive besides /etc/shadow?

 *Quote:*   

> Others may represent system-specific configuration, such as preference on which services to start, how to configure the network, and so on. Identical hardware does not guarantee identical software usage, so even if the files can be shared, that may not be the right choice.

 

That's for sure.

 *Quote:*   

> Why you're syncing those laptops?
> 
> If you want to save some compilation time, you can use portage to build binary packages and then install them (with portage) on the rest.

 

I want to be able to change and maintain a whole slew of laptops by only changing and maintaining my own.  Since the hardware is identical, it really isn't necessary to use portage beyond the "master" laptop.

 *Quote:*   

> I do it with files like /etc/portage, X11.
> 
> I'm the user of both those PCs, so I also have sudo, sshd, polkit & firewall rules. Be careful before sharing those, there could be sensitive information in them (mainly if they're badly configured).

 

What kind of info could be sensitive there?

 *Quote:*   

> http://www.openwall.com/tcb/

 

So tcb is meant to mitigate the kind of risk I'm running into with sharing /etc/shadow?  Is it in portage under another name?

----------

## 666threesixes666

i think tcb is what you're after....  tcb is NOT in portage or in any overlays that i could find.  zunga says its sys-auth/tcb like it did have it at one time.  x86 x86 x86 maybe its because im amd64 that im not seeing it?

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-auth/tcb/?hideattic=0

https://bugs.gentoo.org/show_bug.cgi?id=371167

last comment of the bug says use hardened shadow instead of tcb.

https://code.google.com/p/hardened-shadow/

im not selinux or hardened so idk whats what....  im just digging for info, and sharing what im finding.

----------

## Hu

 *grant123 wrote:*   

>  *Quote:*   Anything in /etc needs to be given special consideration before syncing. As you know, some files in /etc are security-sensitive. 
> 
> Which are potentially security-sensitive besides /etc/shadow?

 PPP / VPN configuration is often stored under /etc, and parts of that are security-sensitive.

----------

## vaxbrat

/etc/shadow and /etc/gshadow for dictionary attacks.

/etc/ssh for the private host keys (the not .pub key files)

/etc/security/opasswd for password history database maintained by pam_unix

Those would be ones I care about in auditd for failed read access attempts.  I also care about failed and any successful writes to anything in /etc.

If you run a dns server you will probably want to watch /etc/bind/rndc.keyLast edited by vaxbrat on Wed Mar 05, 2014 11:48 pm; edited 1 time in total

----------

## grant123

 *Quote:*   

> use hardened shadow instead of tcb

 

hardened-shadow looks like a great thing and it's in portage, but it says:

"Do not use hardened-shadow in production yet. Public auditing process after the first release is likely to detect several security holes. And the codebase needs to mature a bit. Contributors and early adopters are very welcome at this point."

http://code.google.com/p/hardened-shadow/

 *Quote:*   

> PPP / VPN configuration is often stored under /etc, and parts of that are security-sensitive.

 

I don't use PPP or VPN.

 *Quote:*   

> /etc/sshd for the private host keys

 

I had no idea those keys were in /etc/ssh.  What are they used for?

 *Quote:*   

> /etc/security/opasswd for password history database maintained by pam_unix 

 

I don't have that file.

 *Quote:*   

> If you run a dns server you will probably want to watch /etc/bind/rndc.key

 

I don't run a DNS server and I don't have that file.

Thanks to all for helping me lock this down.

----------

## vaxbrat

The keys in /etc/ssh are generated the first time you run sshd on the host and are then used to prevent man in the middle attacks.  When you first ssh into another box and get that "I don't know who this is, do you want to continue?" type prompt, its the host keys that are used to figure this out.  The known_hosts files that end up in your user .ssh directories contain the public key from that pair for each host you know about.

You probably won't see the opasswd on a default install.  It doesn't get needed unless you set the "remember=n" stanza on pam_unix in the password section of the pam system-auth file.  It then stores the hashes of passwords that users create when they go through a change password.  It gets referenced to rub their noses in it when they attempt to recycle an old password that they've used in the last n changes.

----------

## grant123

 *Quote:*   

> The keys in /etc/ssh are generated the first time you run sshd on the host and are then used to prevent man in the middle attacks. When you first ssh into another box and get that "I don't know who this is, do you want to continue?" type prompt, its the host keys that are used to figure this out. The known_hosts files that end up in your user .ssh directories contain the public key from that pair for each host you know about.

 

I'll exclude /etc/ssh/ssh_host_*.

 *Quote:*   

> You probably won't see the opasswd on a default install. It doesn't get needed unless you set the "remember=n" stanza on pam_unix in the password section of the pam system-auth file. It then stores the hashes of passwords that users create when they go through a change password. It gets referenced to rub their noses in it when they attempt to recycle an old password that they've used in the last n changes.

 

I'll exclude /etc/security/opasswd in case I start using it in the future.

It sounds like /etc/shadow is the only sticking point left.  Would you guys share /etc/shadow on your LAN or use hardened-shadow?

 *Quote:*   

> "Do not use hardened-shadow in production yet. Public auditing process after the first release is likely to detect several security holes. And the codebase needs to mature a bit. Contributors and early adopters are very welcome at this point."
> 
> http://code.google.com/p/hardened-shadow/

 

----------

## grant123

Any opinions on that last one?

----------

## SirRobin2318

 *Quote:*   

>  It sounds like /etc/shadow is the only sticking point left. Would you guys share /etc/shadow on your LAN or use hardened-shadow? 

 

No, don't share that file. Hardened shadow doesn't seem ready for production. You could edit the file, remove the password hashes, and recreate them on each machine.

----------

## grant123

Now that I think about it, I'm not sure what the problem is.  /etc/shadow is root:root -rw-r----- so other users can't read it.  Is the danger someone booting a USB stick and reading the file that way?

----------

## SirRobin2318

Yes, of course that's a problem. They might even get root access in other ways. They could boot in single user mode. They could exploit a future  vulnerability that will be documented in glsa. 

We told you it's a bad idea, why are you insisting? At this point, just do what you want.

If security is an issue, you shouldn't be doing this. Separate /etc's, just use binary packages. If you're doing this to share with trustworthy family and friends, sure, why not, but then security isn't an issue.

----------

## grant123

I'm not only trying to keep my systems secure.  I'm also trying to learn about securing them.  I appreciate your help but please don't expect me to follow instructions without understanding why I'm following them.

Having said that, thank you for elaborating.  Isn't /etc/shadow vulnerable in these ways on every system with user accounts?

----------

## SirRobin2318

If you are trying to keep these systems secure you are going about it the wrong way.

Cloning everything and trying to find problematic files is bad. You'd have to know what every file contains. This is not an easy goal. Not only it's not easy but human errors happen, even with loads of experience you would mess up. To limit the amount of information leaking out, you should be taking the problem the other way around: What files am I sure I can share without leaking sensitive data? Sharing everything by default is a Bad Idea.

/etc/shadow has a relatively sane security logic. You could share it and maybe nobody would be able to hack into it. But there are tools that are dead easy to use to exploit any weakness in your choice of passwords. It might take months, but it could work. Why take the chance?

----------

## grant123

I understand that the way I'm doing this isn't conventional or as secure as possible, but there are other benefits to carrying it out this way so I'd like to make it as secure as I can.  It sounds like /etc/shadow is the only clearly identifiable weak point and I'll look into switching to hardened-shadow as soon as it's production-ready.

To be sure I understand, /etc/shadow is always easily readable by anyone with physical access to any Linux system, correct?  What makes this scheme undesirable is that I'm moving one system's /etc/shadow to another system so if the passwords there are cracked, both systems are vulnerable?

----------

## khayyam

 *grant123 wrote:*   

> I understand that the way I'm doing this isn't conventional or as secure as possible, but there are other benefits to carrying it out this way so I'd like to make it as secure as I can.  It sounds like /etc/shadow is the only clearly identifiable weak point and I'll look into switching to hardened-shadow as soon as it's production-ready.

 

grant123 ... I'm not sure where your getting the idea that shadow is "clearly [an] identifiable weak point", perhaps from a previous post that wrongfully stated that MD5 is used, I'm fairly sure that all password hashes are sha512 (well, I may have changed this myself a long time ago, but again I believe this is now the default). As of now no known vulnerabilities have been exposed in sha512, but like anything of this nature it *could* be vulnerable to attack ... however, if you wanted to attack a password mechanism you would go for brute-forcing the password itself rather than the hash (and such is the inherent "weakness" of passphrases). 

 *grant123 wrote:*   

> To be sure I understand, /etc/shadow is always easily readable by anyone with physical access to any Linux system, correct?

 

Incorrect ... the password file is only accessible to root (or via a process running with root privileges, such as 'login').

```
# ls -l /etc/shadow*

-rw-r----- 1 root root 818 2014-03-13 10:23 /etc/shadow

-rw------- 1 root root 796 2014-03-06 00:44 /etc/shadow-
```

 *grant123 wrote:*   

> What makes this scheme undesirable is that I'm moving one system's /etc/shadow to another system so if the passwords there are cracked, both systems are vulnerable?

 

Yes, but the emphasis is on "if" ... and how big an "if" that might be. Its easy to look for potential issues where there are none ... or perhaps better put, these issues are minimal, or the lesser probable weakness. Now, if this worries you why not boot them and run 'passwd' and changing the password on each machine to something unique?

HTH & best ... khay

----------

## eccerr0r

It's a bit of security by obscurity.  Originally hashed passwords all were in a publicly readable file - in /etc/passwd directly.  Before when cracking it was infeasible this was fine.  Now with fairly quick machines and cracking is possible, it's best to make it a bit harder by not providing the hashes and hide them in /etc/shadow.

Ideally if both machines are both "yours" (meaning you own them and always under your control and nobody else), rsyncing the two is no big deal, in fact a bit annoying to the users because you have to change passwords/create accounts on one machine before you sync it else changes can get lost.  If one of the two machines however is shared or not necessarily owned by you and thus not always trust the other machine, then it's best not to share (and look into something like LDAP or Kerberos or worst case YP/NIS and have the authentication server on a third machine).

----------

## 666threesixes666

"check /etc/shadow file as root. Passwords hashed with SHA-256 should begin with a $5 and passwords hashed with SHA-512 will begin with $6." ~ https://wiki.archlinux.org/index.php/SHA_password_hashes

```
kazam@gentoo.org [ ~ ]$ ls -al /etc/passwd

-rw-r--r-- 1 root root 1140 Mar 14 01:33 /etc/passwd
```

```

kazam@gentoo.org [ ~ ]$ cat /etc/passwd

root:x:0:0:root:/root:/bin/bash

bin:x:1:1:bin:/bin:/bin/false

daemon:x:2:2:daemon:/sbin:/bin/false

adm:x:3:4:adm:/var/adm:/bin/false

lp:x:4:7:lp:/var/spool/lpd:/bin/false

sync:x:5:0:sync:/sbin:/bin/sync

shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown

halt:x:7:0:halt:/sbin:/sbin/halt

news:x:9:13:news:/var/spool/news:/bin/false

uucp:x:10:14:uucp:/var/spool/uucp:/bin/false

operator:x:11:0:operator:/root:/bin/bash

portage:x:250:250:portage:/var/tmp/portage:/bin/false

nobody:x:65534:65534:nobody:/var/empty:/bin/false

man:x:13:15:added by portage for man-db:/usr/share/man:/sbin/nologin

sshd:x:22:22:added by portage for openssh:/var/empty:/sbin/nologin

mail:x:8:12:added by portage for mailbase:/var/spool/mail:/sbin/nologin

postmaster:x:14:249:added by portage for mailbase:/var/spool/mail:/sbin/nologin

postfix:x:207:207:added by portage for postfix:/var/spool/postfix:/sbin/nologin

messagebus:x:101:206:added by portage for dbus:/dev/null:/sbin/nologin

polkitd:x:102:205:added by portage for polkit:/var/lib/polkit-1:/sbin/nologin

kazam:x:1000:1000::/home/kazam:/bin/bash

ntp:x:123:123:added by portage for ntp:/dev/null:/sbin/nologin

```

KAZAM!!!!!

----------

## khayyam

 *666threesixes666 wrote:*   

> "check /etc/shadow file as root. Passwords hashed with SHA-256 should begin with a $5 and passwords hashed with SHA-512 will begin with $6."

 

Yes, I'm well aware of that ...

```
# whoami

root

# awk -F'$' '/^root/{print "$"$2}' /etc/shadow-

$6
```

.... and as I said, its *now* the default:

```
# awk '/\+.*sha512/{print}' <(equery -NC u pambase)

 + + sha512 : Switch Linux-PAM's pam_unix module to use sha512 for passwords hashes rather than MD5. This option requires >=sys-libs/pam-1.0.1 built against >=sys-libs/glibc-2.7, if it's built against an earlier version, it will silently be ignored, and MD5 hashes will be used. All the passwords changed after this USE flag is enabled will be saved to the shadow file hashed using SHA512 function. The password previously saved will be left untouched. Please note that while SHA512-hashed passwords will still be recognised if the USE flag is removed, the shadow file will not be compatible
```

 *666threesixes666 wrote:*   

> 
> 
> ```
> kazam@gentoo.org [ ~ ]$ ls -al /etc/passwd
> 
> ...

 

It's "/etc/shadow*" that contains the hashes ... so what has /etc/passwd to do with the above?

 *666threesixes666 wrote:*   

> 
> 
> ```
> kazam@gentoo.org [ ~ ]$ cat /etc/passwd
> ```
> ...

 

Again, what has /etc/passwd to do with it?

 *666threesixes666 wrote:*   

> 
> 
> ```
> kazam:x:1000:1000::/home/kazam:/bin/bash
> ```
> ...

 

Wrong ... everyone here knows I'm a long time zsh user/advocate.

 *666threesixes666 wrote:*   

> KAZAM!!!!!

 

As I warned you previously this is now reported ... and btw, your only making your self look silly with this poor attempt at proving me wrong and the silly name calling ...

khay

----------

## John R. Graham

@666threesixes666, please play nicely. It'll help you avoid an all expenses paid vacation.

- John

----------

## SirRobin2318

 *Quote:*   

> I'll look into switching to hardened-shadow as soon as it's production-ready.

 

You will still have the exact same problem. Hardened shadow will not help you if the users have root access. As you said earlier, all they need to do is boot with a live CD, or just take the hard drive out and plug it in another machine. 

https://lwn.net/Articles/487620/

 *Quote:*   

> Originally, /etc/passwd contained a hashed version of each account's password. The file itself was readable by any user, which enabled features like looking up usernames by their UIDs, and other tricks unrelated to the passwords themselves. The trouble was that attackers could calculate hashes offline then compare their results against /etc/passwd looking for matches. Shadow shuts down that attack vector by separating the hashed password information into a separate file that is readable only by trusted processes. In a sense, both tcb and hardened-shadow take that same approach: separating unrelated information further to reduce the potency of attacks.
> 
> Taking care of passwords
> 
> Openwall's tcb mechanism stores salted-and-hashed passwords in a directory of its own, /etc/tcb/, beneath which there is a separate directory for each user. Each user's directory is owned by that user account, and contains their own private shadow file (e.g., /etc/tcb/linus/shadow) also owned by the user.

 

 *Quote:*   

> To be sure I understand, /etc/shadow is always easily readable by anyone with physical access to any Linux system, correct? What makes this scheme undesirable is that I'm moving one system's /etc/shadow to another system so if the passwords there are cracked, both systems are vulnerable?

 

That is correct. And hardened shadow would not help you. 

Once again, if security is an issue, do not share that file. Or run passwd and make different passwords for each machines.

----------

## khayyam

 *SirRobin2318 wrote:*   

>  *Quote:*   To be sure I understand, /etc/shadow is always easily readable by anyone with physical access to any Linux system, correct? 
> 
> That is correct. And hardened shadow would not help you.

 

I now see I'd misread the above, if users have "physical access" then the bios should be password protected to prevent users booting from CD's, USB sticks, etc, and the bootloader should be password protected to prevent changes to the boot parameters, etc, (ie, lilo or via grub).

best ... khay

----------

## SirRobin2318

 *Quote:*   

> I now see I'd misread the above, if users have "physical access" then the bios should be password protected to prevent users booting from CD's, USB sticks, etc, and the bootloader should be password protected to prevent changes to the boot parameters, etc, (ie, lilo or via grub). 

 

And the hard drive should be encrypted so you can't read it from another machine. 

Oooor you could not share /etc/shadow so it doesn't even matter if a user gains root access.

----------

## khayyam

 *SirRobin2318 wrote:*   

> And the hard drive should be encrypted so you can't read it from another machine. 

 

hehe ... and/or the case should be locked with a padlock (many/most cases come with such things) ... and the keyboard cable should be glued in its slot so no hardware keylogger can be inserted :)

 *SirRobin2318 wrote:*   

> Oooor you could not share /etc/shadow so it doesn't even matter if a user gains root access.

 

.... ooooooor a centralised authentication mechanism should used and pam_unix disabled ... or a RBAC (role-based access control) should be used to limit the root account ... the list goes on :)

best ... khay

----------

## depontius

 *khayyam wrote:*   

>  *SirRobin2318 wrote:*   And the hard drive should be encrypted so you can't read it from another machine.  
> 
> hehe ... and/or the case should be locked with a padlock (many/most cases come with such things) ... and the keyboard cable should be glued in its slot so no hardware keylogger can be inserted 
> 
>  *SirRobin2318 wrote:*   Oooor you could not share /etc/shadow so it doesn't even matter if a user gains root access. 
> ...

 

You forgot the sub-basement, the alligators, etc.  Oh, and put it somewhere on a planet around Alpha Centauri, for even better measure.

Or just take hedge shears to the network cable.

----------

## SirRobin2318

 *Quote:*   

> .... ooooooor a centralised authentication mechanism should used and pam_unix disabled ... or a RBAC (role-based access control) should be used to limit the root account ... the list goes on  

 

Yes. My point it is all this could be avoided easily. Instead of trying to protect valuable information, don't give it away in the first place.

----------

## khayyam

 *SirRobin2318 wrote:*   

> My point it is all this could be avoided easily. Instead of trying to protect valuable information, don't give it away in the first place.

 

SirRobin2318 ... ok, perhaps we were talking at cross purposes, or better put, at different tangents. I had somewhat put the question of /etc/shadow to rest and had moved on to the wider question of "security". I *would* in this instance change the password on the various cloned machines ... however ... if the machines in question were exposed to users then /etc/passwd wouldn't be my first concern, I would be more concerned about far easier ways in which the machine might be compromised ... and a security policy that reflects this. So, *before* I might even consider login I would think about the boot procedure (bios and bootloader), physical security (of both the machine and user input), and access controls (including a centralised authentication mechanism ... though this may not be a workable solution for laptops). As I tried to point out earlier: its easy to look for issues where there are none (or that exist only minimally), and so miss the obvious. Even if a machine was rooted sha512 would still need to be broken, or the passphrase brute-forced/keylogged, and though thats a possibility the real concern should be with the methods that someone might get this root access rather than focus on ways of securing /etc/passwd exclusively.

 *depontius wrote:*   

> You forgot the sub-basement, the alligators [....]

 

I did, thats because alligators are sooooooo 1980's ... flesh eating bacteria is where its at nowadays :)

 *depontius wrote:*   

> [...] and put it somewhere on a planet around Alpha Centauri, for even better measure.

 

Oh yeah? You gonna drive to Alpha Centauri every time udev needs updating? :)

best ... khay

----------

## depontius

 *khayyam wrote:*   

> ...
> 
>  *depontius wrote:*   You forgot the sub-basement, the alligators [....] 
> 
> I did, thats because alligators are sooooooo 1980's ... flesh eating bacteria is where its at nowadays 
> ...

 

You're making me feel old - when HHGtG references are no longer automatically spotted.  Obviously for systems around Alpha Centauri you want a good, reliable boot mechanism, along with a reliable ssh daemon configuration, etc.  

I've looked at some of what grub can do in the way of safe/backup boots, but never really implemented any of that.  For several years I maintained my mother's Gentoo system from 600+ miles away.  One time (pretty good, given the number of years we were running this way.) I had to have a cousin come to her house and press the up-arrow once on the grub menu.

The other solution would of course be IPMI, but lately that seems like jumping from the frying pan into the fire, security-wise.

----------

