🚀 go-pugleaf

In article <62524@cup.portal.com> VESOFT@cup.portal.com (Michael D Hensley) writes:
>Agree/disagree/discussion: Any root-owned world-writable file should be
>considered a potential security loophole.
>What do you think?

Only if the system trusts the contents of the file, or root executes it,
or the uid or gid bit is set (on those weird variations of UNIX that don't
clear the bits when the file is modified).  Otherwise, what could you
possibly do that would create a security problem, just because the file is
owned by root and not, say, nobody?

(I am aware that the file could be used to get around quotas, if applicable,
but I don't really consider that a security loophole.  The worst a user could
do is fill up the file system, but that results in no permanent damage.
Just one less user.  :-))

-- 
John C. Fowler, jfowler@lanl.gov

VESOFT@cup.portal.com (Michael D Hensley) writes:
>Agree/disagree/discussion: Any root-owned world-writable file should be
>considered a potential security loophole.

Only if it can somehow be executed OR it is something that a current
executable references as trusted information.

One can also ask: "Is it really necessary to have a world writable file
owned by root?"

-- 
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

   There is no greater calamity for a nation or individual
                 than not finding contentment in one's sufficiency.

jfowler@beta.lanl.gov (John C. Fowler) writes:

>Only if the system trusts the contents of the file, or root executes it,

How do you get a complete list of files that are trusted by root, or by
programs that root trusts (that is, are setuid root)?

Much easier to simply not have world-writable files owned by root.

-- 
    Tim Ramsey, 913.532.6750
    Department of Mathematics
    Kansas State University

In article <62524@cup.portal.com> VESOFT@cup.portal.com (Michael D Hensley) writes:
>COPS doesn't seem to report ALL root-owned world-writable files.
>
>Agree/disagree/discussion: Any root-owned world-writable file should be
>considered a potential security loophole.

There is a good argument for both sides:

Disagree - It is only a security hole if it is a program that somebody
(root or otherwise) will run or if it contains data that you trust for
system security.  If I make /tmp/junk in single user mode and then
leave it there world writeable, it is only a hole if it is also readable
and contains data you don't want to get out.

Agree - _Any_ world writeable file is a de-facto security hole because
any random user can change it.  For example, /users/fred/.login is
a security hole if it is world writeable.  /users/fred/phone_numbers
is also a form of security hole, since by writing to it, I could
probably cause Fred to make telephone calls to the wrong people.

btw.. beware of things that are supposed to be world writeable: e.g.
on many machines, /usr/dict/spellhist is world writeable.  (It collects
lists of words that people spell wrong.  It has no special security
because you don't really _care_ if it gets trashed.  All it is good for
is identifying words that _might_ belong in the dictionary.  This in itself
could be a security hole, if you have people spell-checking documents
that contain sensitive information.)

In article <14htt0INNiep@hilbert.math.ksu.edu> tar@math.ksu.edu (Tim Ramsey) writes:
>How do you get a complete list of files that are trusted by root, or by
>programs that root trusts (that is, are setuid root)?

To find out if a file is trusted, go to the man directories and grep the
filename on everything, then read the associated man pages where the filename
turned up (important files usually have their own man pages as well).

To find setuid root files, use the "find" command.

>Much easier to simply not have world-writable files owned by root.

Agreed.  Much easier to simply not have world-writable files at all, unless
you can come up with a real reason for needing them.  With UNIX supporting
setuid and setgid programs, it's fairly easy to work around these days.

But I still contend that there's nothing "special" about root owning a
world-writable file that would allow a user to exploit it over anyone else
owning the same file, other than getting around quotas.

-- 
John C. Fowler, jfowler@lanl.gov

VESOFT@cup.portal.com (Michael D Hensley) writes:
>Agree/disagree/discussion: Any root-owned world-writable file should be
>considered a potential security loophole.

Strongly disagree.  The only difference between it being owned by root and
owned by someone else (discounting quotas) is that if it's owned by root,
someone else can't chmod or chown it.  This is an INCREASE in security.
Especially in these days of NFS, where people can become anyone other than root
with physical access to a workstation.  (Well, they can become root, but then
they're "nobody" over NFS.)

You could argue that files shouldn't be world-writable, but I don't see how you
can argue that given that a file is world-writable (but not set[ug]id), it's a
danger to have it be owned by root rather than daemon or nobody or something.

tar@math.ksu.edu (Tim Ramsey) writes:
>How do you get a complete list of files that are trusted by root, or by
>programs that root trusts (that is, are setuid root)?
>
>Much easier to simply not have world-writable files owned by root.

Not having world-writable files owned by root has nothing to do with this.  If
root or a setuid-root program trusts a world-writable file, the fact that it is
owned by someone else doesn't help you.

In article <1992Jul22.134745.17309@newshost.lanl.gov>, jfowler@beta.lanl.gov (John C. Fowler) writes:
>In article <14htt0INNiep@hilbert.math.ksu.edu> tar@math.ksu.edu (Tim Ramsey) writes:
>>How do you get a complete list of files that are trusted by root, or by
>>programs that root trusts (that is, are setuid root)?
>
>To find out if a file is trusted, go to the man directories and grep the
>filename on everything, then read the associated man pages where the filename
>turned up (important files usually have their own man pages as well).
>
>To find setuid root files, use the "find" command.
>
>>Much easier to simply not have world-writable files owned by root.
>
>Agreed.  Much easier to simply not have world-writable files at all, unless
>you can come up with a real reason for needing them.  With UNIX supporting
>setuid and setgid programs, it's fairly easy to work around these days.
>
>But I still contend that there's nothing "special" about root owning a
>world-writable file that would allow a user to exploit it over anyone else
>owning the same file, other than getting around quotas.
An exception occurs to me in the case of /etc/utmp under SunOS 4.1.1 - the mode
this is set to by default is 666, hence it is world writeable.
If you reedit this with a simple C Program, you can make yourself invisible to
who commands etc. and also can evade certain accounting programs.

>
>-- 
>John C. Fowler, jfowler@lanl.gov
Jon Care, jonc@sc.plym.ac.uk.

In article <14htt0INNiep@hilbert.math.ksu.edu>, tar@math.ksu.edu (Tim Ramsey) writes:
 -- How do you get a complete list of files that are trusted by root, or by
 -- programs that root trusts (that is, are setuid root)?
 -- 
 -- Much easier to simply not have world-writable files owned by root.

So does that mean we should cease to make /tmp world-writeable ? 
It certainly would induce people to stick closer to POSIX :-)

Otherwise, I disagree, world writeable files are not a security problem,
inappropriate use of information in files is the problem. It is also a
problem that people try to deduce the contents of files from the file names.
Unfortunately this is very deeply embedded in unix, or rather in the 
common usage that is made of unix facilities.

I seems however that the management problem that the use of filename 
'constants' (like /etc/passwd for the password file) gives people will
be felt before the security problem.

                                        Thomas

-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ cc.ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic.cc on Janet)
*   voice: +44 715 895 111 x4937 or 4934 (day), or +44 718 239 497 (fax)
*   snail: Imperial College Center for Computing Services, Kensington SW7 2BX