[sclug] Centralised Authentication

[Dickon Hood]

On Mon, Oct 31, 2005 at 16:46:14 +0000, John Stumbles wrote:
: Peter Brewer wrote:
: >Ok, so LDAP is definitely the 'proper' way to do it, but I'm intrigued 
: >by David's solution.  I know that it is slightly less than conventional, 
: >but if it works what are the drawbacks?  From what I've read, the LDAP 
: >approach is far from simple.  We're talking about managing a dozen 
: >machines here, not an entire lab full - isn't LDAP a hammer to crack a nut?

: For a group of machines isolated from the Big Bad Internet and from 
: untrustworthy users it's fine, but  it'd be vulnerable from a security 
: pov in a hostile environment. If you're just exporting/mounting 
: /etc/passwd that implies you're not using shadow passwords so the passwd 
: hashes are in /etc/passwd which can be sniffed from the network or read 
: by a user on any of the client machines (and then subjected to a 
: crack/jack/john attack)

You could quite happily do exactly the same thing with /etc/shadow as
well.

: I'm sure all sorts of other 'interesting' attacks would be possible too :-)

One or two, but if NFS is exported and you have physical access to the
network, it's game over anyway.

NFS is a nice protocol in a trusted environment, but it's a bit of a
nightmare elsewhere.  Having written both a client and server (NFSv2 and
v3) I can confidently say that...

NFS doesn't protect from a man-in-the-middle attack, so it's trivially
possible to sit on the network as a clone of another machine and bombard
it with the appropriate traffic.  NFS' security model is essentially
client-side only -- ie, it expects the clients to honour the Unix
filesystem semantics, rather than rely on the server rejecting
unauthorised attempts (which it will do anyway) -- as the credentials
passed from the client to the server to identify a user amount to nothing
more than the UID and list of GIDs that the appropriate process has at
that time.  This makes it trivial to say 'I'm root -- gimme!' at it, and
it'll happily do so (unless root's mapped to some non-root user, which is
sane, and happens a lot).  But as files on the filesystem are rarely owned
as root, and it's very rare that these special users' IDs are mapped,
there's nothing stopping you from assuming that identity too.  There is
such as thing as DES authentication, but RPC's authentication is weak in
that it only protects the header of the request, making an attack
marginally harder rather than virtually impossible.  RPCGSS is a wrapper
over the top, which is supposed to be better still, but I've never seen a
site implement it...

Adding NIS into the mix -- where you have all the clients trusting the
server, essentially, with no cryptographic anything anywhere -- is merely
the icing on the cake.  Couple the whole lot with one of the leakiest
daemons known to man -- portmap -- and you soon start to cry.

In short: if you want something faintly secure, LDAP is probably your
friend, assuming you can't get Kerberos to do what you want.

-- 
Dickon Hood

Due to digital rights management, my .sig is temporarily unavailable.
Normal service will be resumed as soon as possible.  We apologise for the
inconvenience in the meantime.

No virus was found in this outgoing message as I didn't bother looking.