From owner-freebsd-security Thu Jan 25 15:20:46 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA16777 for security-outgoing; Thu, 25 Jan 1996 15:20:46 -0800 (PST) Received: from multivac.orthanc.com (root@multivac.orthanc.com [206.12.238.2]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA16763 for ; Thu, 25 Jan 1996 15:20:33 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id PAA07296; Thu, 25 Jan 1996 15:18:31 -0800 (PST) Message-Id: <199601252318.PAA07296@multivac.orthanc.com> X-Authentication-Warning: multivac.orthanc.com: Host lyndon@localhost didn't use HELO protocol From: Lyndon Nerenberg VE7TCP To: Paul Richards cc: security@freebsd.org Subject: Re: bin owned files In-reply-to: Your message of "Thu, 25 Jan 1996 11:38:47 GMT." <199601251138.LAA24328@cadair.elsevier.co.uk> Date: Thu, 25 Jan 1996 15:18:26 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Paul" == Paul Richards I am having a really tough time wrapping my head around this. Paul> Getting bin access does not give you root access. and then Therefore, the only Paul> way to get root access from bin is to replace, say, /bin/sh Paul> with a program that creates a suid root sh *when it is run Paul> by root*. Well, which one is it? Your own example completely invalidates your first assertion. If there is an implied "immediately" in "does not give you root access," please say so. Your own example shows that bin access allows root access. How quickly is based soley upon "bin's" skill. Paul> If you log in as root and don't realise that there Paul> has been a compromise of bin then that is your problem but Paul> in and of itself a bin compromise is safer than a root Paul> compromise for the reasons I previously explained. What reasons? Again, Again I invoke your example above. How is this "safer" than if the files were root owned? Paul> All other arguments relate to NFS and I refuse to even Paul> discuss NFS in this context. Why? If the argument breaks your proof, ignoring the argument does not make your proof valid. Paul> If you crack root anywhere on Paul> an NFS system then the whole system is compromised and while Paul> making things owned by root makes it a little harder it is Paul> no protection. I'm still not clear on why root ownership is "no protection?" To my way of thinking, there is little *effective* difference in actual security in the root-vs-bin ownership case, other than the greater ease in attacking non-root files over NFS. Someone else mentioned that bin ownership helped save administrators from themselves. I invite any of you to run 'rm -rf /' under bin's uid (as per the "accidentally chmod u+s a bin owned program" example given previously), and tell us the results. What all of this demonstrates is that having certain files owned by bin gives you nothing more than a false sense of security. I don't know the origin of the bin id. Can anyone out there state *definitively* the reason for bin's creation? My gut feeling is that it was created to make 'ls -l' look a bit prettier, and vendors have been blindly copying the convention for years now without giving any thought as to the real need for such an account. Things have changed a lot since the days of seventh edition (or wherever bin appeared - it's been around for as long as I can remember), and maybe it's time we rethought the reasons for, and consequences of, a seperate bin id? --lyndon