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?

Are databases secure?

[rueba]

Can these databases be made as secure as /etc/passwd?
Just curious....

PAM is your friend here

[William Aoki]

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.

Actually, I just realized another problem with a database and no /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.

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

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

Actually, after typing all this I realized that NIS and NIS+ are really just databases that take the place of /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.

Disclaimer: I'm tired, so this post may contain various sundry weirdness or inaccuracies. Check your manpages before doing anything rash.

Using a database...

[kwalker]

Hmm... Well, technicalities aside, the advantages that I can see are:

1) No /etc/password to crack. Protects users from their own stupidity if they have easy passwords.
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.

Some various forms of non-/etc/passwd logins

[Matthew Weigel]

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.

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 /etc/passwd).

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.

Speed is the pro

[tjansen]

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

Re:Using a database...

[jmalicki]

Actually, you still have a DATABASE to crack. So the point is moot. And they in all likeliness use the same encryption schemes. At least every solution that I've seen does.

And actually, it is a much simpler setup when installing a box, because you dont have to do passwd/shadow/group mirroring, which can be quite a bitch and can open up security holes...

Re:Speed is the pro

[jmalicki]

You can do the same on a libc6 system w/ nsswitch.conf

NSS

[ÿ]

NSS is the Name Service Switch. It was invented by Sun and is now also supported by NetBSD, and GNU libc 2 based systems (e.g. recent Linux systems).

NSS allows you to specify the source for system databases, such as the passwd database. From info libc:

Various functions in the C Library need to be configured to work

correctly in the local environment. Traditionally, this was done by
using files (e.g., `/etc/passwd'), but other nameservices (like the
Network Information Service (NIS) and the Domain Name Service (DNS))
became popular, and were hacked into the C library, usually with a fixed
search order.

The GNU C Library contains a cleaner solution of this problem. It is
designed after a method used by Sun Microsystems in the C library of
Solaris 2. GNU C Library follows their name and calls this scheme
"Name Service Switch" (NSS).

Writing and using self-written NSS modules is easy. Look at www.padl.com [padl.com] who offer a NSS module for LDAP integration.
--
OS lover

PAM and Kerb

[Lour]

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?"

kerberos

[lysander]

Perhaps you should look into Kerberos [mit.edu], a system developed at mit and used in several other places.

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.

alternate passwd databases

[jjw129]

This is exactly the problem I'm trying to find a good solution for right now..

Sun's NIS/NIS+ is, essentially, a database being queried for user and network information, queried instead of /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
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.

This is done all of the time with NIS+

[Rubinstien]

But be careful. We have a >$1M software package,
running against Oracle, that broke when we moved
to NIS+. It parsed /etc/passwd directly instead
of using getpwent and friends. Fortunately, that
high price tag included source.

UNICOS's UDB?

[Troy Baer]

UNICOS (the Cray UNIX) has a system called the UDB (user database) which includes all of the information in /etc/passwd plus information on resource limits and some other stuff. There's still an /etc/passwd file, but I don't think it's used for much. Unfortunately I can't find any links on SGI [sgi.com]'s site describing how the thing works.

--Troy