Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!lth.se!newsuser
From: magnus%thep.lu.se@Urd.lth.se (Magnus Olsson)
Newsgroups: comp.unix.admin
Subject: Re: Kmem security (was: Re: How do you make your UNIX crash ???)
Message-ID: <1991Mar26.113637.24279@lth.se>
Date: 26 Mar 91 11:36:37 GMT
References: <513@bria> <1991Mar12.132003.27383@cs.widener.edu> <1991Mar18.153201.23325@lth.se> <601@minya.UUCP>
Sender: newsuser@lth.se (LTH network news server)
Reply-To: magnus@thep.lu.se (Magnus Olsson)
Organization: Theoretical Physics, Lund university, Sweden
Lines: 27

In article <601@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>In article <1991Mar18.153201.23325@lth.se>, magnus%thep.lu.se@Urd.lth.se (Magnus Olsson) writes:
>> That doesn't mean, of course, that you can't get passwords from /dev/kmem -
>> login has to keep the entered password somewhere before it encrypts it!
> 
>Sorry, but this is bogus.
> 
>True, login has to keep the password somewhere, but that somewhere isn't
>in /dev/kmem; it is in login's address space.
>
>What is true is that it has to get it from somewhere, and it does that via
>a read(), meaning that the somewhere it gets it from is inside /dev/kmem.
>
>[Picky, picky, picky!  ;-]


To be *really* picky, I didn't say that login *did* keep passwords in /dev/kmem, 
but only that it wasn't necessarily true that it didn't. :-)

Seriously, I thought the entire virtual memory of the machine was accessible
through /dev/kmem. Why isn't login's address space?

Magnus Olsson                   | \e+      /_
Dept. of Theoretical Physics    |  \  Z   / q
University of Lund, Sweden      |   >----<           
Internet: magnus@thep.lu.se     |  /      \===== g
Bitnet: THEPMO@SELDC52          | /e-      \q