Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!uunet!mcsun!hp4nl!htsa!miquels From: miquels@htsa.htsa.aha.nl (Miquel van Smoorenburg) Newsgroups: comp.os.minix Subject: Re: Curses Message-ID: <119@htsa.htsa.aha.nl> Date: 14 Jun 91 09:41:10 GMT References: <}0K*`?+@cck.cov.ac.uk# <33563@usc.edu> Organization: Polytechnical Institute AHA-TMF, Amsterdam, The Netherlands Lines: 34 In article <33563@usc.edu# kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: #In article <}0K*`?+@cck.cov.ac.uk> csg020@uk.ac.cov.cck (***CURTIS***) writes: #>Also, has anyone noticed that if you strings /dev/kmem it shows up everyones #>decrypted password who has logged on since the bring up of the system?! # #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). # #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. # #Perhaps an easy solution is to have the login program, and the su #program, go and scribble over each copy of entered passwords after they #are used. Both login and su should be able to do this since they are #both suid. Any comments on this idea? Should it go into 1.6.* right #away? # #-- #favourite oxymorons: student athlete, military justice, mercy killing #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. -- --- % Miquel van Smoorenburg, Baljuwstraat 20, 2461 SL Langeraar, Holland % % miquels@drinkel.nl.mugnet.org miquels@maestro.htsa.aha.nl % % God is real, unless declared integer.. %