Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!crackers!cpoint!frog!rmkhome!rmk
From: rmk@rmkhome.UUCP (Rick Kelly)
Newsgroups: comp.unix.admin
Subject: Re: Kmem security
Message-ID: <9103231800.12@rmkhome.UUCP>
Date: 24 Mar 91 04:18:00 GMT
References: <513@bria> <1991Mar12.132003.27383@cs.widener.edu> <14454@ulysses.att.com> <1991Mar13.180300.17697@convex.com> <9103152251.41@rmkhome.UUCP> <4331@skye.ed.ac.uk>
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Lines: 27

In article <4331@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes:
>In article <9103152251.41@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
>>Think about it.  Look at the UNIX tools you have available.  Consider the fact
>>that /dev/kmem is a file.  When anyone logs in, even root, login has to decrypt
>>the password in /etc/password to compare it to the password typed it.  This
>>password in memory lays around for a while.

>Though the user's password is stored in memory temporarily, it is
>*not* the case that the encoded password in /etc/password is
>decrypted.  After all, if login could decrypt it, so could you.  The
>password the user types is used as a key to encrypt a fixed string
>(all zeros) and the result is compared with the data from the password
>file.


Yes, I have already posted that I was thinking backwards that day.  However,
when you type in your passwd, it sits around in memory, and stock UNIX tools
can be used to equate your login name with your passwd.  I have done it on
demand for people who wanted to know why kmem should't be world readable.


I'm extremely sorry for posting without my mind engaged.  I will probably
hear about it for the next 2 months.  At least Jonathan Kamens hasn't sent
me any mail yet.


Rick Kelly	rmk@rmkhome.UUCP	frog!rmkhome!rmk	rmk@frog.UUCP