arneme@birger.uit.no (Arne Munch-Ellingsen) (07/26/90)
Last night something weird happend on one of our Unix machines (a Sun 3/60 running SunOs 4.0.3) : The permissons on the device files /dev/kmem and /dev/mem was changed from 644 to 640. This resulted in that users running programs opening and reading either kmem or mem complained about it not working. At the same time users started complaining about that rsh and rlogin was not working properly. The following error message occured: rcmd: socket: Permission denied Does anyone know what this means, and how to fix it? Has anyone experienced this happening on their machines, and what is causing it? Help needed!
mtr@geech.ai.mit.edu (Michael Rowan) (07/26/90)
Having kmem readable by everyone is a security problem, if you care about such things. Some make programs that use kmem (ps for one) sgid kmem (with kmem grouped to kmem mode 640) mtr
debra@alice.UUCP (Paul De Bra) (07/27/90)
In article <1990Jul26.102810.4816@hod.uit.no> arneme@sfd.uit.no writes: >Last night something weird happend on one of our Unix machines (a Sun >3/60 running SunOs 4.0.3) : > >The permissons on the device files /dev/kmem and /dev/mem was changed >from 644 to 640. This resulted in that users running programs opening >and reading either kmem or mem complained about it not working... /dev/kmem and /dev/mem should never have been 644 in the first place. Allowing any process to read kernel memory means that one can get a process to peek at tty input buffers and things like that. (so any time anyone types his password, whoops...) Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jik@athena.mit.edu (Jonathan I. Kamens) (07/27/90)
(Note the Followup-To and cross-posting -- no offense intended, but if this had been a wizard-level question, the original poster would have understand what was going on.) In article <1990Jul26.102810.4816@hod.uit.no>, arneme@birger.uit.no (Arne Munch-Ellingsen) writes: |> The permissons on the device files /dev/kmem and /dev/mem was changed |> from 644 to 640. This resulted in that users running programs opening |> and reading either kmem or mem complained about it not working. As someone already pointed out, having /dev/kmem and /dev/mem world-readable is a serious security hole (i.e. "all bets are off"), and my guess is that someone at your site who is concerned about security changed the permissions on it. As someone else has also already pointed out, systems which are concerned about security should make the permissions on /dev/kmem and /dev/mem 640, assign group kmem to them, and make all system programs (netstat, pstat, ps, etc.) setgid kmem. |> At the |> same time users started complaining about that rsh and rlogin was not |> working properly. The following error message occured: |> |> rcmd: socket: Permission denied |> |> Does anyone know what this means, and how to fix it? Has anyone |> experienced this happening on their machines, and what is causing it? Rsh and rlogin both have to connect to a local socket with a port number that is less than 1024. Such ports are "secure" on Unix systems, which means that only programs with superuser access can connect to them. It sounds to me like somebody, either accidentally or intentionally, turned off the setuid root bits on your rsh and rlogin binaries. Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
jc@minya.UUCP (John Chambers) (08/10/90)
In article <MTR.90Jul26123451@geech.ai.mit.edu>, mtr@geech.ai.mit.edu (Michael Rowan) writes: > > Having kmem readable by everyone is a security problem, if you care > about such things. Some make programs that use kmem (ps for one) sgid > kmem (with kmem grouped to kmem mode 640) Watch out for clever changes from some vendors. A couple months back, I noticed that /bin/ps on a Convex was setuid-root, and brought this to the manager's attention. He agreed it was silly, and we changed it to setgid-kmem. It seemed to work fine. But within minutes he started getting calls from puzzled users about ps being broken. When we looked closer, we found that it would only show all processes if its euid was 0, and other mere mortals were restricted to seeing a list of their own processes. We decided that this was a totally bogus pseudo-security non-feature, and changed it back to setuid-root so that users could see what was happening. Maybe we were wrong. Does anyone know why they would do something so silly? Well, yeah, I know how to use the process table as a covert data channel; I've even implemented a demo of the technique. But if you're that security-crazed, I can't imagine allowing ps in the first place. (For that matter, it'd probably be better to just simply ban multi-programming. ;-) Anyone out there with the inside story? -- Zippy-Says: I was there when ELMER FUDD met HAMLET on the MOON. Uucp: ...!{harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc (John Chambers) Home: 1-617-484-6393 Work: 1-508-952-3274