bug#10010: "su" *should* check on SUID bit

[Bob Proulx]

severity 10010 wishlist
tags 10010 + confirmed
thanks

Michael Lenz wrote:
> just yesterday I stumbled across a little problem in su when I
> recursively fucked up the ownership of "/" on a colocated box..

Ouch!  And of course it is remote making it twice as difficult to
repair.  I feel for you.  How extensive was problem?

> Thereafter I could ssh into that box as an unprivileged user, but
> was unable to use sudo, because SETUID root was missing on it as
> sudo kindly told me.

Does that mean that sudo lost the suid but was still owned by root?
Or that sudo's ownership had also changed along with / to something
else?

> Aaand I was unable to su to root, due to an "invalid password",
> which was strange..

And I am sure very frustrating at the time.

> I thougt I knew the password and tried several permutations of it,
> but none worked, so I got my root's password reset by a local
> operator.
> Guess what: The box didn't want to "su" me to root with the new
> password either, but I could ssh into the box with address@hidden and the
> new password..

Oh good.  You found an avenue to log in as root.  The running sshd
daemon had previously been started with superuser permissions and so
could spawn other processes as root without need for suid-root
capability.

> After some research I found out that "su" needs to be SUID to root
> as well, but it obviously does not check on this file property.

There are many system programs that need to be sui-root in order to
operate correctly.  I have 27 on my system at the moment.  The su
program will need access to the protected /etc/shadow file in order to
obtain access to the encrypted passwords stored there.

> I therefore advise calling stat() before checking on the user's
> password and eventually throwing an error message.. ;)

One problem is that different systems have such wildly different
security access models that it is hard to generalize.  SELinux for
example hardly has a 'root' model.  Others are completely different.
This means that the program needs privileges to do at least two
separate things.  One is to be able to authenticate the user such as
by being able to read the /etc/shadow file.  The other is that it
needs to be able to spawn a shell by the specified user.  Having good
error messages in both cases is desirable and they may be different.
But it is hard to check for every possible failure that might occur on
a system because there are an infinite number of ways for a system to
be broken.

But first, we need to check one very particular thing.  You didn't say
what system you were running this upon.  Not every system uses the
coreutils su for the system su command.  Some run su from other
projects.  What does 'su --version' say on your system?

  su --version

Just to check that the reporting is to the right project and not to
one of the other su implementations.

In any case, I did try this using GNU coreutils su (of an older
vintage) and this was the result:

  # chmod u-s /bin/su
  # ls -l /bin/su
  -rwxr-xr-x 1 root root 39948 2008-11-03 04:11 /bin/su

  $ su
  Password: 
  su: incorrect password

That does seem less than friendly and seems like it would be good to
be improved.

Thanks
Bob