Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!widener!ukma!memstvx1!utkcs2!emory!wuarchive!usc!elroy.jpl.nasa.gov!swrinde!mips!pacbell.com!ucsd!ucrmath!nuchat.sccsi.com
From: kevin@nuchat.sccsi.com (Kevin Brown)
Newsgroups: comp.os.minix
Subject: Re: Unencoded passwords in /dev/mem
Message-ID: <15249@ucrmath.ucr.edu>
Date: 13 Jun 91 20:59:50 GMT
References: <}0K*`?+@cck.cov.ac.uk> <33563@usc.edu> <15237@ucrmath.ucr.edu>
Sender: news@ucrmath.ucr.edu
Reply-To: kevin@nuchat.sccsi.com (Kevin Brown)
Organization: Teenage Mutant Ninja NiceGuys [tm] :-)
Lines: 35

In article <15237@ucrmath.ucr.edu> I write:
>The superuser is able to find out other users' passwords anyway, because
>he is in a perfect position to write a "trojan horse" program that's
>completely transparent, i.e. by modifying login.com to save away the
>password somewhere.

Er...login.c, that is.

Must be one of those days.  :-(

Sigh.  And I've been trying to run away, far away, from VMS...:-(

(Those of you not familiar wit VMS should know that the "login.com" file
is a script in the user's home directory that gets executed whenever
they log in.  The VMS equivalent of .profile)

>>This is a most serious security hole.  It also means that on PC's that
>>aren't running in protected mode, and maybe Macs, have no security at
>>all.

Turns out that protected mode operation doesn't help too much here, at
least on the PC.  I dunno.  

BTW, I expect that protecting /dev/mem is a *lot* more important to 68K 
Minixers, since the 68K series does memory-mapped I/O.  Imagine the *weird*
things a nasty user could do with write access to /dev/mem (even on an
Intel-based system, but it's worse on the 68K, I think)...


--
Kevin Brown						    Disclaimer: huh?
kevin@nuchat.sccsi.com				kevin@taronga.hackercorp.com
...!uunet!nuchat!kevin			      ...!uunet!nuchat!taronga!kevin

Minix -- the Unix[tm] of the 90's.  System V -- the Multics of the 90's.  :-)