: tequila.cs.yale.edu> writes:
: >> Indirectly, programs that need access to the shadow password file
: >> will have to be SUID. SUID programs are vulnerable attack. There are
: >> known problems with old versions of SUID xlock for example.
: S> That's why it makes sense to make /etc/shadow readable by group
: S> "shadow" and make xlock setgid shadow instead of setuid root. This
: S> way, an xlock security hole will allow reading /etc/shadow but will
: S> not give immediate root access.
: OK SGID "shadow" programs would stop root breakins. The risk is reduced to
: having a false sense of security with shadow passwords.
The cynic in me wonders if you're trolling this sort of
fatalism out in order to encourage people to leave their
systems more vulnerable.
What is the false sense of security here? I can make
my hashed passwords trivially available to anyone who gets
any local user access to my system, so they can immediately
launch dictionary and brute force searches -- or I can
(at no administrative or financial cost) prevent them from
*trivially* getting the data that makes these attacks
I can close and latch the front door, or I can leave it
wide open. Closing it means they need to pick the lock,
steal a key, mug one of my roommates on the way in, or
start kicking and hope my neighbors don't come over and
shoot them. DUH! Sounds like a tough choice to me.
Yes, I still recommend enforcing a policy that requires
"strong" passwords. npasswd or passwd+ are options.
Although it's highly unpopular -- I'd like to see
people stop *picking* passwords at all. I generate
random strings of printable characters for all the
root passwords that I have to deal with (which is
way too many since I consult for a number of
organizations: I keep trying to get them to limit
me just to temporary 'sudo' access -- and they keep
giving me full root!).
Note: I haven't heard anyone here try to sell shadow
passwords as any sort of panacea. The design solves one
particular problem. Decent implementations (which DON'T
use SUID/root!) don't increase the risk profile. Great,
now we move on to the next problem.
(The "next problems" in this case are many and varied --
and the ubiquitousness of access protocols that pass
authentication informations (reusable passwords!) in
plaintext over untrusted media (ethernet LAN's and the
Internet itself) is at the top of my list).
So now that local users have to find a good bug in a
a narrow range of programs to get at your shadow
file -- let's quit sending the plaintext around in
the clear. I'll even grant that it's a much worse
problem and should have been dealt with first.
Our choices seem to be Kerberos, ssh and S/Key
(and numerous others -- but let's just mention the
really popular ones).
Starshine Technical Services http://ww.starshine.org