Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Is /etc/shadow safe?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
grant123
l33t
l33t


Joined: 23 Mar 2005
Posts: 771

PostPosted: Fri Mar 14, 2014 11:06 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Mar 15, 2014 12:31 am    Post subject: Reply with quote

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').

Code:
# 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
Back to top
View user's profile Send private message
eccerr0r
Advocate
Advocate


Joined: 01 Jul 2004
Posts: 4007
Location: USA

PostPosted: Sat Mar 15, 2014 4:45 am    Post subject: Reply with quote

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).
_________________
Intel Core i7 2700K@ 4.1GHz/HD3000 graphics/8GB DDR3/180GB SSD
What am I supposed to be advocating?
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1241
Location: 42.68n 85.41w

PostPosted: Sat Mar 15, 2014 5:30 am    Post subject: Reply with quote

"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

Code:
kazam@gentoo.org [ ~ ]$ ls -al /etc/passwd
-rw-r--r-- 1 root root 1140 Mar 14 01:33 /etc/passwd



Code:

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!!!!!
_________________
cat /etc/*-release
Funtoo Linux - baselayout 2.2.0
consider this warning no. 1
https://wiki.gentoo.org/index.php?title=Special:Contributions/666threesixes666&offset=&limit=500&target=666threesixes666
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Mar 15, 2014 11:24 am    Post subject: Reply with quote

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 ...

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

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

Code:
# 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:
Code:
kazam@gentoo.org [ ~ ]$ ls -al /etc/passwd
-rw-r--r-- 1 root root 1140 Mar 14 01:33 /etc/passwd

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

666threesixes666 wrote:
Code:
kazam@gentoo.org [ ~ ]$ cat /etc/passwd

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

666threesixes666 wrote:
Code:
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
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7840
Location: Somewhere over Atlanta, Georgia

PostPosted: Sat Mar 15, 2014 12:19 pm    Post subject: Reply with quote

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

- John
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
SirRobin2318
Apprentice
Apprentice


Joined: 24 Apr 2004
Posts: 213
Location: Strasbourg, france.

PostPosted: Sat Mar 15, 2014 12:47 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Mar 15, 2014 1:43 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
SirRobin2318
Apprentice
Apprentice


Joined: 24 Apr 2004
Posts: 213
Location: Strasbourg, france.

PostPosted: Sat Mar 15, 2014 2:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Mar 15, 2014 2:32 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2586

PostPosted: Sat Mar 15, 2014 3:13 pm    Post subject: Reply with quote

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.

.... 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


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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
SirRobin2318
Apprentice
Apprentice


Joined: 24 Apr 2004
Posts: 213
Location: Strasbourg, france.

PostPosted: Sat Mar 15, 2014 3:15 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Mar 15, 2014 10:54 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 2586

PostPosted: Mon Mar 17, 2014 12:07 pm    Post subject: Reply with quote

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 :)

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


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.
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum