Date: Wed, 24 Jan 1996 15:32:43 -0800 From: Lyndon Nerenberg VE7TCP <lyndon@orthanc.com> To: Paul Richards <p.richards@elsevier.co.uk> Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601242332.PAA13164@multivac.orthanc.com> In-Reply-To: Your message of "Wed, 24 Jan 1996 20:08:31 GMT." <199601242008.UAA19526@cadair.elsevier.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Paul" == Paul Richards <p.richards@elsevier.co.uk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601242332.PAA13164>