OS files owned by bin not root

[tony_b...@my-deja.com]

-r-xr-xr-x 1 bin bin 7024 Sep 1 1998 cal
-r-xr-xr-x 1 bin bin 6580 Sep 1 1998 asa
-r-xr-xr-x 1 bin bin 1162 Sep 1 1998 diff3
-r-xr-xr-x 1 bin bin 21484 Sep 1 1998 acctcom
-r-xr-xr-x 1 bin bin 25692 Sep 1 1998 bc
-r-xr-xr-x 1 bin bin 6920 Sep 1 1998 unexpand
<much snippage>
But i don't know WHY this is a risk, and consequently, whether or not i
should recommend that the owner of these file should be changed to root.

can anyone advise or point to relevant docs?

TIA

Tony

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[Scott Cromar]

As a general rule, files on root's path and the parent directories of such
files should be owned by root. In addition, neither of the above classes
of objects should be writable by anyone other than root. This same rule
also extends to items not on root's path which are run by root (or by a
root cron job). Otherwise, someone who is able to hack "bin" or "daemon"
or whatever can drop a trojaned version of a binary into someplace where
root may execute it. The rest is left as an exercise to the reader...

(Note: the above rules should probably be extended to a number of files
that are executed by other users, since executing a trojaned file could
lead to a compromise of a user account.)

--Scott

[Dan Harkless]

Scott Cromar <cro...@Princeton.EDU> writes:
>On Mon, 14 Jun 1999 tony_b...@my-deja.com wrote:
>
>> -r-xr-xr-x 1 bin bin 7024 Sep 1 1998 cal
>> -r-xr-xr-x 1 bin bin 6580 Sep 1 1998 asa
>> -r-xr-xr-x 1 bin bin 1162 Sep 1 1998 diff3
>> -r-xr-xr-x 1 bin bin 21484 Sep 1 1998 acctcom
>> -r-xr-xr-x 1 bin bin 25692 Sep 1 1998 bc
>> -r-xr-xr-x 1 bin bin 6920 Sep 1 1998 unexpand
>> <much snippage>
>> But i don't know WHY this is a risk, and consequently, whether or not i
>> should recommend that the owner of these file should be changed to root.
>

>As a general rule, files on root's path and the parent directories of such
>files should be owned by root. In addition, neither of the above classes
>of objects should be writable by anyone other than root. This same rule
>also extends to items not on root's path which are run by root (or by a
>root cron job). Otherwise, someone who is able to hack "bin" or "daemon"
>or whatever can drop a trojaned version of a binary into someplace where
>root may execute it. The rest is left as an exercise to the reader...

Usually hacking bin and daemon are harder than hacking root, though, since
root almost certainly has a valid password and shell and those accounts
don't.

I'm more interested in the question of why the tradition of making system
files owned by 'bin' was started. The tradition has not ceased in all the
UNIXen I'm familiar with, so it would seem there's some reason...

---------------------------------------------------------------------------
Dan Harkless | NOTE: Due to SPAM I have implemented a caller-ID-
d...@wave.eng.uci.edu | like policy for this account. Put "re-send" in
Unitech Research, Inc. | your Subject to bypass or finger me for more info.

[Doug Siebert]

Dan Harkless <d...@wave.eng.uci.edu> writes:

>Usually hacking bin and daemon are harder than hacking root, though, since
>root almost certainly has a valid password and shell and those accounts
>don't.

Not necessarily, there are sometimes security holes of "lets you get any
account but root" flavor. Especially, but not always, where NFS is
involved. I seem to recall sendmail had one of these three or four
years ago.

HP-UX is one of those annoying systems that has all the binaries owned
by 'bin' and not 'root. I have found that doing chown of all bin owned
stuff on the system to root (be sure and double check nothing is setuid
bin, just in case, as kermit is setuid bin for some odd reason) doesn't
break anything. Well, not much -- a couple things in inetd.conf are run
as bin and only executable by their owner, but that's an easy fix.

Of course, having a setuid bin binary and fingerd and auth run as bin
from inetd.conf are possible security holes waiting to happen. Exploit
those, then you can put the passwd file of your choice into place due to
/etc being owned by bin and bingo, you have root. That's why I do the
chown to make everything owned by root even though I'm not NFS exporting
the OS portion of any system.

--
Douglas Siebert Director of Computing Facilities
douglas...@uiowa.edu Division of Mathematical Sciences, U of Iowa

I plan to live forever, or die trying.

[Theo de Raadt]

dsie...@icaen.uiowa.edu (Doug Siebert) writes:

> Not necessarily, there are sometimes security holes of "lets you get any
> account but root" flavor. Especially, but not always, where NFS is
> involved. I seem to recall sendmail had one of these three or four
> years ago.
>
> HP-UX is one of those annoying systems that has all the binaries owned
> by 'bin' and not 'root. I have found that doing chown of all bin owned
> stuff on the system to root (be sure and double check nothing is setuid
> bin, just in case, as kermit is setuid bin for some odd reason) doesn't
> break anything. Well, not much -- a couple things in inetd.conf are run
> as bin and only executable by their owner, but that's an easy fix.
>
> Of course, having a setuid bin binary and fingerd and auth run as bin
> from inetd.conf are possible security holes waiting to happen. Exploit
> those, then you can put the passwd file of your choice into place due to
> /etc being owned by bin and bingo, you have root. That's why I do the
> chown to make everything owned by root even though I'm not NFS exporting
> the OS portion of any system.

It's kind of funny. It's perhaps 7 years after people became commonly
aware of this issue, but today most systems still screw up in most of
the ways you talk about..

--
This space not left unintentionally unblank. der...@openbsd.org
Open Source means some restrictions apply, limits are placed, often quite
severe. Free Software has _no_ serious restrictions. OpenBSD is Free Software.