Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!mips!swrinde!elroy.jpl.nasa.gov!usc!pollux.usc.edu!kjh
From: kjh@pollux.usc.edu (Kenneth J. Hendrickson)
Newsgroups: comp.os.minix
Subject: Re: Curses
Message-ID: <33610@usc.edu>
Date: 14 Jun 91 22:54:12 GMT
References: <}0K*`?+@cck.cov.ac.uk# <33563@usc.edu> <119@htsa.htsa.aha.nl>
Sender: news@usc.edu
Organization: EE-Systems, USC, Los Angeles
Lines: 25
Nntp-Posting-Host: pollux.usc.edu

In article <119@htsa.htsa.aha.nl> miquels@htsa.htsa.aha.nl (Miquel van Smoorenburg) writes:
>In article <33563@usc.edu# kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes:
>#This is bad.  Not only because ordinary users may be able to find out
>#the root password (if the superuser isn't so smart), but also because
>#the superuser is able to find out other users passwords (if he is).
>#Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh
>
>Nope. A user should not be able to read from /dev/[k]mem. If he can,
>that's wrong. And on a PC (or Mac?) it is not only possible to READ
>all the memory, but also to WRITE it. So there is no security anyway.
>(Just change the kernel's proc table, the UID field ofcourse)
>Miquel.

Well, Miquel, I am not so stupid.  Please read my post again, quoted for
your convenience.  "If the superuser isn't so smart" translates to
having world read and write permissions on /dev/*mem, and "if he is"
translates to having them protected.

However, on a PC that is not in protected mode, a user can write a
program to read from any memory location he pleases, even one that isn't
in *his* address space.

-- 
favourite oxymorons:   student athlete, military justice, mercy killing
Ken Hendrickson N8DGN/6       kjh@usc.edu      ...!uunet!usc!pollux!kjh