From owner-freebsd-security Wed Jan 24 15:37:03 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA00773 for security-outgoing; Wed, 24 Jan 1996 15:37:03 -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 PAA00768 for ; Wed, 24 Jan 1996 15:36:55 -0800 (PST) Received: from localhost (lyndon@localhost) by multivac.orthanc.com (8.7.3/8.7.3) with SMTP id PAA13164; Wed, 24 Jan 1996 15:32:47 -0800 (PST) Message-Id: <199601242332.PAA13164@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: Ownership of files/tcp_wrappers port In-reply-to: Your message of "Wed, 24 Jan 1996 20:08:31 GMT." <199601242008.UAA19526@cadair.elsevier.co.uk> Date: Wed, 24 Jan 1996 15:32:43 -0800 Sender: owner-security@freebsd.org Precedence: bulk >>>>> "Paul" == Paul Richards writes: Paul> The real point against you're argument is segregation of Paul> priviliges. Why give any more privilage to a binary than is Paul> necessary. If a binary doesn't need to be root then don't Paul> make it owned by root at all and then if something goes Paul> wrong, like you mistakenly suid a bin binary and not realise Paul> it, the possible damage is less than if it was a root Paul> binary. This is where you are wrong. It is the *same* as if a root binary were compromised? Why? Because sooner or later that bin-owned binary is going to be run by root. Let's look at your example. You accidentally chmod u+s something owned by bin. What you have here is the potential for *any* user with access to the chmoded command to replace *any* file in /sbin, /usr/sbin, /bin, and /usr/bin. Why? Because these directories are writable by the user 'bin'. This gives you the ability to whack files in those directories that aren't even *owned* by bin. Not to mention the ones that are. Imagine the consequences of this setuid-bin program causing /sbin/init to be unlinked. Harmless? The setuid-bin program can also do things like replace /bin/ls. How long will it be before root runs the new-and-improved ls? As long as root runs bin owned binaries, bin is equivelent to root. Period. Paul> This segregation is more to do with protecting Paul> sysadmins from themselves than it is about preventing Paul> break-ins and the added segragation is *NOT* a potential Paul> security hole since those uid's do not have passwords and Paul> therefore *cannot* be cracked in and of themselves. You Paul> *have* to crack root first. The point about bin is that the Paul> system is not owned by an actual user. Nonsense. Perhaps the easiest attack available is to NFS mount your /usr from a workstation where I have root access. Like this: % su # mount unsecure:/usr /mnt # su bin > rm -f /mnt/bin/more; cp /my/new/and/improved/more /mnt/bin Now, the next time you run the more command as root on your system, my fixed up version wanders off and creates any one of a million possible backdoors into your system. I've just broken root on your box, soley through the use of this "harmless" bin user. And this is just *one* example. [ Note: this is just an example to make point. I'm not stating that this, or any other, specific attack will work. Everybody's machine is a bit different. Let's not get sidetracked from the main issue. ] Some systems are foolish enough to ship with the /etc directory owned by bin. Guess what happens when I can unlink and replace /etc/passwd? Paul> Sysadmins make mistakes, if you make a potentially serious Paul> mistake with a bin owned system binary the possible damage Paul> is limited to bin owned files. If you make a mistake with a Paul> root owned file it's a different matter. To summarize: if root runs bin-owned binaries, bin is root. To pretend otherwise is wrong (and dangerous). --lyndon