Date: Thu, 25 Jan 1996 09:19:23 -0600 From: William McVey <wam@fedex.com> To: Paul Richards <p.richards@elsevier.co.uk> Cc: security@freebsd.org Subject: Re: bin owned files Message-ID: <199601251517.AA04710@gateway.fedex.com>
next in thread | raw e-mail | index | archive | help
Paul Richards wrote: >Therefore, the only way to get root access from >bin is to replace, say, /bin/sh with a program that creates a suid root >sh *when it is run by root*. Which occurs whenever cron executes something on behalf of root. How about all those executables owned by bin but run by root from within inetd? How about init? or /bin/login (which may not be owned by bin, but is in a bin-owned directory, so is therefore exposed). >If you log in as root and don't realise that >there has been a compromise of bin then that is your problem but in and >of itself a bin compromise is safer than a root compromise for the >reasons I previously explained. There have been several examples given where the real administrator plays no role in running the trojan horse... running executables is a system function root performs all the time, not just during interactive login sessions. >All other arguments relate to NFS and I refuse to even discuss NFS in this >context. If you crack root anywhere on an NFS system then the whole >system is compromised and while making things owned by root makes it >a little harder it is no protection. I can masquerade as many other users >and find other ways to do what I want. The whole point is, there *was* >a root break-in, the fact that it wasn't the actual server box is not an >issue. NFS cannot be regarded as a number of separate machines from >a security context, a compromise on one is a compromise on them all. No, this is not necessarly the case. I was an administrator for a lab of 200+ workstations with NFS mounts from a few central file servers. A compromise on one the workstations (in a public lab with few real physical security precautions) did *NOT* result in a compromise of the servers. The clients were considered expendible since they were reloaded every semester. User data was at risk, but this was well known and instructors were informed to not keep sensitive data on the lab cluster. -- William
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601251517.AA04710>