Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!ora!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.wizards Subject: Re: Problems with permissions on sockets. Message-ID: <433@minya.UUCP> Date: 9 Aug 90 23:58:07 GMT References: <1990Jul26.102810.4816@hod.uit.no> Lines: 29 In article , 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