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>
index | next in thread | previous in thread | raw e-mail
>>>>> "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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601242332.PAA13164>