[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: non-root password lookups? [LONG]



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

Shadow passwords do stop every local user from being able to FTP the encrypted
passwords to some fast machine that runs crack.

>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

If using /var/spool/mail then I would have the mail server programs run as
group mail and owner of mail, nobody, or anything else but root.  Preferrably
I'd also give those daemons no write access to their own files (apart from
sendmail which only works well if the binary is SUID to the same user as it's
run from inetd).  Thus someone who abuses a broken mail server can do nothing
worse than reading and modifying other people's mail.  As long as people don't
email passwords around the hacker will get no other access.
I've setup machines with sendmail and various POP clients in this way so that
no mail server ever gets access to read/write anything outside /var/spool/mail.

An alternative is to run Qmail with the Qmail POP server but no IMAP (when I
installed Qmail there was no IMAP server for it).  This has no known security
related bugs.

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

This relies on you unwisely running an imapd as root.  Just don't do that. 
Don't point guns at your feet!

>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

1) Why not make things harder for them even if passwords are good?
2) Often the administrator can't force all users to select good passwords.  I'm
sure that many people on this list have been in situations where less
intelligent managers or customers have forced them to allow short passwords that
are easy to remember.

--
I am in London and would like to meet any Linux users here.
I plan to work in London for 6 months and then I might move to some other
place where the pay is good.


Reply to: