On Tue, 19 Jan 1999, Chris wrote: > Can you explain what the problem with a auth daemon is? If there was a > daemon listening on a system port then why couldn't local processes be > sure that it is the real thing (since its the same machine anyway - if > a skript kiddie can fake the daemon running on a system port then he > has root anyway)? What am I missing?
In short: I can't see and never could see that a daemon to do that offers me any protection over just having my crypt(3)ed passwords in /etc/passwd, and could in fact be detrimental (see below). People who use stupid passwords (names, birthdates, etc.) deserve what they get. If you need more security than 56-bit DES passwords in /etc/passwd provide, shadow passwords and/or rpc.pwdauthd (or a variation thereof) is _not_ the Right Answer(tm) - some kind of one-time pad (OTP, à la S/KEY) or public/private key encryption (à la PGP or ssh) is. I suggest that this is growing somewhat off-topic for debian-mentors; perhaps debian-devel is a more appropriate forum? In long: Let's pretend that you are the administrator for a small company's network. There's a bunch of boxes, some more secure than others. Scenario 1: You use the mail server on your desk as a workstation from time to time. One day, Mr Cracker finds a vulnerability in the imapd on your box. He crawls through it, and proceeds to trojanize /bin/login and /usr/sbin/imapd. He is careful to not mess up the a/c/mtimes on the file. Three months later, you upgrade imapd. Mr Cracker notices that imapd isn't gathering passwords and stashing them in a safe place any more, so he re-trojanizes it. Quite by accident, you notice that the imapd upgrade didn't stick, and investigate - and find that your system has been compromised. How long has he been there? What has he been doing, other than gathering passwords? How many users' passwords has he secretly obtained? He hasn't managed to obtain _your_ password this way, since you never use IMAP, but what about the boxes other people telnet/ssh to from your machine? Have they been compromised? Time to reinstall everything and try again. In Scenario 1, the cracker only trojanized imapd, and therefore only collected passwords from users who used imapd. Scenario 2: You use the mail server on your desk as a workstation from time to time. One day, Mr Cracker finds a vulnerability in the imapd on your box. He crawls through it, and proceeds to trojanize /sbin/rpc.pwdauthd. He is careful to not mess up the a/c/mtimes on the file. Three months later, you notice a suspicious file in /usr/bin that seems to contain every password - even incorrect attempts - that's been typed on your system for the last three months. This time, _anything_ that uses passwords has been indirectly compromised, and you're going to have a fun month reinstalling every server on your network to make sure the cracker isn't hiding somewhere else on your network. <rant> rpc.pwdauthd is a bandaid over making programs that access /etc/shadow suid root or sgid shadow. I'm not convinced that even /etc/shadow is necessary. Providing you have even halfways decent passwords, you don't have a lot to worry about. If you have people in Black Hats coming after you with the budget to build the EFF's 56-bit DES cracker machine (or an even faster one), chances are that: a) you're screwed anyway, or b) you're sufficiently important that you've already taken every possible measure to protect against compromise, like shutting off unnecessary and superfluous services and using Real Encryption(tm), and sophisticated monitoring systems. It is a _lot_ easier to replace /sbin/rpc.pwdauthd with a trojanized version than, say, to replace libc or system services, because it has a _lot_ less moving parts. libc is a very good example of something with a lot of moving parts - just recently, for example, I upgraded libc6 on my home machine, which cased _every single program I'd compiled myself_ to break. (__register_frameinfo, anyone?) I concede that breakages like that are _rare_, but there's still enough moving parts in libc that can be snapped off by accident to guard against (IMHO) someone putting a libc with a trojanized crypt(3) in a rootkit. (In fact, rootkits are a good way for cracker wannabes to be detected - they typically contain programs that are sufficiently dissimilar to cause major things to fail and bring the problem to someone's notice.) We recently found that a server here had been compromised (via, it appears, the imapd from Bo that somehow got missed when the machine was upgraded to Hamm) _in November, 1998_. I only noticed it because I found an unaccouted-for user in /etc/passwd. If he hadn't done that, but instead trojanized /sbin/rpc.pwdauthd, who _knows_ how long he might've lain there, undetected? </rant> -- Jeffrey Sean Connell | Networking/Telecommunications Engineer, GXC [EMAIL PROTECTED] | PGP key at http://www.canuck.gen.nz/~ankh/pgpkey.html ---------------------+-------------------------------------------------------
