Slashdot Mirror
UNIX Machines that don't use /etc/passwd
A Nameless Submmitor had this question to bring before you all: "I've heard of and had access to several machines that don't use passwd/shadow files or even wtmp for user logging/authentication, but instead use Oracle databases, or other methods. My question is, what's the story on this approach, what are the pros/cons, and is there anything out there for Linux that is similar?" There are SEVERAL options of this available for Linux, but just what do you all think
about using a database for user authentication?
Can these databases be made as secure as /etc/passwd?
Just curious....
The only reason all cover-ups appear to fail is that you never hear about the ones that succeed.
If you're trying to implement this, I think that PAM (pluggable authentication modules) is the way to go. You could write (or see if someone else has written) modules that talk to the database and will allow any program that authenticates using PAM to use your database instead of /etc/passwd.
/etc/passwd. You would need to write a wrapper for getpwent and friends and link all the programs on your system against it (can be accomplished by modifiying the libc or tinkering with runtime linker configuration) for the programs to find out information such as your name, home directory, people's usernames, etc. Without the wrapper, you'd run into all sorts of problems because there would be no reliable way to find out said info. I suppose that you could also have the database put out required info into /etc/passwd whenever it's changed for the use of ls, sh, and friends.
/etc/passwd and /etc/shadow, and possibly more secure for programs like xlock and passwd because they wouldn't need to be suid to work; xlock could submit a password and the database could tell it if the password is okay, and passwd would be a program to run a query containing the old password and the new password. login, sudo, sshd and associated programs would still need to run as root or be suid to work unless the system implements capabilites, so the database wouldn't work here. A database system would also be nice in a cluster; every host could authenticate off an authentication server (like NIS).
/etc/shadow implementations don't let users see their own password hashes and slow down the users's own password querries to keep the user from brute-forcing his own password.
/etc/passwd, /etc/shadow, and other friendly /etc files. You could use them as your auth database if you want to, and since they've been around for ages libc already understands 'em; any program that uses libc calls for /etc/passwd and /etc/shadow can use them without changes (see /etc/nsswitch.conf). I don't have experience with RADIUS, so I'm not sure how it deals with authentication and *pwent issues, but I imagine it would also fit the bill.
Actually, I just realized another problem with a database and no
Woops, I just realized another possibility - plug it in like NIS or NIS+ plug in. Run a fake ypbind that really talks to your database instead of NIS.
In theory the database should be at least as secure as
I see two potential disadvantages with the database system. One is, of course, the overhead imposed by running queries into it for authentication, but it probably wouldn't be noticable unless on an ancient, slow, loaded system. The other is that if any program is allowed to query things such as passwords, it makes it much easier to brute-force passwords unless the database slows access on password querries. The database dosen't need to allow a user to query any password but the user's own, but even then,
Actually, after typing all this I realized that NIS and NIS+ are really just databases that take the place of
Disclaimer: I'm tired, so this post may contain various sundry weirdness or inaccuracies. Check your manpages before doing anything rash.
Hmm... Well, technicalities aside, the advantages that I can see are:
/etc/password to crack. Protects users from their own stupidity if they have easy passwords.
1) No
2) No local password files to crack if you can break root on that machine (See point 1).
3) Central management of passwords.
4) Passwords probably don't use the same encryption scheme. Security through obscurity.
Cons:
1) If the password server is down, no one--NO ONE--could get in. (Could get around this, depending on how they have it setup)
2) Non-standard password setups, so new admins must be trained in their security model. (They might consider that an advantage)
3) More complex setup when installing a new box.
With Linux, you can use NIS, LDAP, and several others to do the same thing. For a large system, it might not be too bad of an idea.
Improvise, adapt, and overcome.
NIS, of course, the venerable; I remember reading that NetInfo was ported to Linux, but I haven't been able to find it; I think Kerberos counts here as well, sorta.
/etc/passwd).
Overall, they're nice for some things, but also sometimes a PITA. As a sysadmin, I like being able to add users manually using vi, and I've had some unpleasant experiences with NetInfo (and NIS is insecure compared to
Of course, I'm not too experienced with NetInfo, NIS, or Kerberos. So YMMV, but rest assured that the inconveniences of dealing with a particular database authentication system pay for themselves with the convenience of managing large sites with a database in general.
--Matthew
The most important reason is speed. Reading and parsing a text file each time you need information about a user is very slow if you have a huge number of users. For example, FreeBSD and OpenBSD maintain Berkeley dbm databases of the users to make look-ups faster (but for compatibility reasons, /etc/passwd is still available).
NSS allows you to specify the source for system databases, such as the passwd database. From info libc:Writing and using self-written NSS modules is easy. Look at www.padl.com who offer a NSS module for LDAP integration.
--
OS lover
OS lover
Two methods that I know of and use are PAM modules, and kerberos. PAM is by far the easiest, you just plug it in (as the name suggests) and it connects to some third machine for authentication. With kerberos you can also (although not suggested) replace the login executable with the krb5login, thus making all logins go through the kerberos server. Each method adds another layer to manage and a sysadmin must realize this before doing it, and ask "Is it worth all the trouble, and would it be easier/better to just tighted security on the machine?"
-Lord Shadow
I'd think the way to go nowadays is to use user login/password via LDAP with the extra security of certificates. Thus, even though you have the correct password and username, you still need the certificate. Security, may even be enhanced more with session certificates vs. time based ones.
After authenticating a user logging in, it inserts a placeholder line in /etc/passwd (with the password field as *); this /etc/passwd gets reset when the machine restarts.
GET YOUR WEAPONS READY! --DR.LIGHT
This is exactly the problem I'm trying to find a good solution for right now..
/etc/passwd, /etc/hosts..blah. NIS+ stores all of its data inside database tables within a hierarchy. Entries can contain information of just about any kind, but there are standard tables people create for passwords, services, etc. NIS+ is good because it's
Sun's NIS/NIS+ is, essentially, a database being queried for user and network information, queried instead of
1. secure
2. got fine-grain access control on db objects
3. doesn't conflict with dns (as I have heard nis does unless you configure it properly)
4. allows sharing of basic network/user information for a large number of hosts.
5. The client is easy to set up on solaris.
It's bad because:
1. The admintools and db schema can be very difficult to learn.
2. The server is a pain to set up.
3. The server only runs on solaris.
4. The clients can be a bit difficult to set up on linux, because you usually have to rebuild glibc and reconfigure PAM.
I am looking for a better solution to use on my network right now. I'm managing a departmental network of 8 sun/solaris boxen and 6 intel/linux boxen, using a sun as the nis+ domain controller. We are slowly migrating to using only linux machines as the suns get old, and I'd like to find a server that runs under linux. Standard NIS is an option, but this involves taking a big step backwards in security. I've read that you should only use NIS on private LANs or networks behind a firewall, because anybody can request NIS maps from the network. I've also read that standard NIS can conflict with dns resolution unless you configure it carefully. Doesn't really sound like a viable option for me.
I was reading the documentation at www.padl.com and it looks like you don't get much of a security advantage by using their gateway. If it's simply replacing the dbm backend of nis with an ldap backend, you're still inheriting all the problems with nis. I guess the advantage is the scalability and portability of running off of an ldap server. It's a bit excessive for my needs, but probably perfect for an ISP.
But be careful. We have a >$1M software package, /etc/passwd directly instead
running against Oracle, that broke when we moved
to NIS+. It parsed
of using getpwent and friends. Fortunately, that
high price tag included source.
"My life's work has been to prompt others... and be forgotten." --Cyrano de Bergerac