Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.admin
Subject: Re: Kmem security (was: Re: How do you make your UNIX crash ???)
Message-ID: <11464@dog.ee.lbl.gov>
Date: 26 Mar 91 19:28:01 GMT
References: <513@bria> <1991Mar12.132003.27383@cs.widener.edu> <1991Mar18.153201.23325@lth.se> <601@minya.UUCP> <1991Mar26.113637.24279@lth.se>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 26
X-Local-Date: Tue, 26 Mar 91 11:28:01 PST

In article <1991Mar26.113637.24279@lth.se> magnus@thep.lu.se
(Magnus Olsson) writes:
>Seriously, I thought the entire virtual memory of the machine was
>accessible through /dev/kmem. Why isn't login's address space?

(NB: the following are generalisations that may not apply to your
particular Unix system.)

/dev/kmem gives access to kernel virtual address space.  If login's
address space happens to be mapped in to kernel virtual space at
the time, it could be found there.  If not, it could not.

/dev/mem gives access to physical memory.  In conjunction with
/dev/kmem, this can be used to locate any in-core pages of any
process.  (First one reads the mapping structures from the kernel,
in order to locate the page locators, then one reads the locators,
then the pages.  The total number of indirections involved is
machine- and implementation-dependent.)

The /proc file system, where it exists, gives access to the virtual
address spaces of individual processes.  This is an interesting place
to find covert channels (want to read kernel memory? run a setgid-
kmem program and open its /proc file, if the system permits).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov