There is also the principle of "least surprise", which argues against
making implicit and nonstandard actions that the user did not ask for. If
we clear that bit we are going against standard UNIX practice, so far
verified on SunOS 4, Solaris 2, AIX, IRIX, and even SCO. That's not to say
we shouldn't do it, but we had better have a very compelling reason to be
that nonstandard.
And for the security implications, experienced system administrators expect
that chowning files to root could be dangerous, and shouldn't be done
without the same caution required when adding setuid bits.
> % I'm also skeptical there is any compelling security reason to drop setuid
> % when root is doing a chown/chgrp, if root can chown it root can just as
> % well chmod it again afterwards.
>
> One could make the exact opposite argument: Since root can chmod the file
> afterwards, there is no need to preserve the bits; root can always restore
> them if that's what it really wants.
I can buy this in the case of non-root files chown'd to root; though not in
the case of setgid files being chown'd or setuid files being chgrp'd or
setuid nonroot files being chown'd to another nonroot user.
> In any case there is a security problem: When chowning any file there is
> a race condition where the owner sets the suid bit just before the chown
> (so chmoding it first doesn't help) and executes the file just afterwards
> (so chmoding it after doesn't, either). This means that root chowning
> *any* file while the old owner is running a process exposes the new owner
> to a break-in by the old. I don't see any way around this except crossing
> one's fingers and hoping the old owner doesn't luck out and get the timing
> right.
This is true, but this race condition might exist even if the clearing of
the suid bit is done in the kernel, it requires checking on what the lower
levels of chown/chmod do for locking. This might even be
file-system-specific.
> % Also, if root chowning causes bits in
> % permissions to be cleared, it can result in some utilities not preserving
> % permissions as expected when doing copies and restores (depending on the
> % order the utility does the chown and chmod in).
>
> This is a problem that would exist anyway, since this behavior is normal
> for non-root users. And since Linux utilities are already used to the old
> behavior, this bug would mostly be fixed already. (And personally, I'd
> rather risk a few slightly buggy tools than a potential security exploit
> in the kernel.)
I don't think this security risk is very large, but OTOH the value of not
clearing setuid bits when chowning to root is fairly small. Here's what I
suggest:
- Figure out what the remaining UNIX OSes do (BSD, Compaq/Digital UNIX, and
HP/UX). I am a bit concerned about Linux being completely nonstandard, and
even if no-one else does what is proposed it would be a good idea to
document this in the code and man page. OTOH POSIX and Linux98 clearly
permit the proposed behavior and the current behavior.
- If someone would like to code up a patch for the narrow case of chown to
root of non-root setuid files, please go ahead and send it to Alan and
Linus for review. Note that the locking needs to be looked into. Also
chowns to nonroot and chgrps should not clear the bits, nor should a chown
to root clear setgid bits, nor should sgid or suid bits be cleared on
directories. Only the narrow case should be changed.
I haven't heard comment by Linus; Alan doesn't feel strongly on this issue
and in the narrow case indicated neither do I aside from my concern about
nonstandard behavior.
--- David C Niemi ---niemi at tux.org--- Reston, Virginia, USA ---
But only the man who cares about something in itself, who loves
it and does it *con amore*, will do it in all seriousness. The
highest achievement has always been that of such men, and not of
the hacks who serve for pay. -- Arthur Schopenhauer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/