setperms on linux

[Fairlight]

On Wed, Apr 12, 2006 at 06:53:11PM -0400, after drawing runes in goat's blood,
Kenneth Brody cast forth these immortal, mystical words:
> Quoting Brian K. White (Wed, 12 Apr 2006 18:23:31 -0400):
> [...]
> > Is it just me or is it just plain inexcusably broken for chown to even
> > _touch_ the chmod bits??
> [...]

It's just Brian.  (And anyone else not conversant in security.)

> I vaguely remember this from many years ago as a security issue.  On
> some systems, chown is allowed to change an ownership from the current
> uid to something else.  (Though I think chown is now executable only
> by root, eliminating this problem.)  Imagine creating an executable,
> setting the setuid bit, and then chown root'ing it.

That was indeed a hole.  On some systems you could chown files off of
yourself and onto someone else.  This was changed for several reasons:

1) It allowed the above issue with suid.

2) It allowed users to bypass filesystem quotas.  You could just create
a file and chown it onto someone else's account and keep under your quota
"officially" while technically being well over it.

Ken is right in that chown became root-restricted on many systems.
However, not all systems were changed.

Actually, I personally think tar should strip SUID bits.  Some versions
do, I believe, but not all.  It's pointless (and indeed harmful) unless you
can guarantee UID portability--which is a joke to anyone not running NFS,
usually, where you MUST maintain UID continuity--or guarantee that it does
it by username->uid lookup.

> However, if only root can chown a file nowadays, the setuid-bit removal
> may be overkill.

It's not -all- systems on which it's been changed.  SCO 5.6 lets you chown
away from yourself.  I just did it on someone's system.  It's only on the
sane ones.  :)  I've verified that Linux (as old as Cobalt 6.4 [RH 6.2 era])
and Solaris (5|2).[78] both act in the newer secure fashion.  I don't know
any version of OpenServer that acts properly in restricting chown -by
default-.  Maybe UnixWare does, but I don't have access to one of those
anymore.  I do have access to a 5.0.6 system that won't let me chown away
from myself, but it also implements quotas.  I would expect the change is
quite possibly (maybe even probably) bound to that system being enabled.
On Linux, you're barred from a chown away from yourself even if quotas are
not enabled.  It's probably fixed in Solaris as well.

IOW, SCO meets its usual security standards. *cough* At least it does strip
the SUID bit in the process on systems in which its inherently allowed, but
that's not actually enough.  Wish I had an IRIX system to check with--I'd
be willing to bet they haven't addressed it either.

And I'd lay $5 that any of the *BSD's handle it in the most secure fashion.

Oh, now here's a gem.  I got thinking about tar, right?  WORSE:  rsync!  I
just rsync'd a file that's 4755 fairlite on my linux box to a totally
different account on Solaris.  It maintained the suid bit.  I can't believe
that.  Very tempted to submit that as a vulnerability.  That's just wrong
on so many levels.  There's -no- mechanism for matching users there.

But hey...Brian might think it's sane.

mark->
-- 
I do not suffer fools lightly--ignorant fools much less so.