Re: Tracing by uid u after root does setuid(u)

[James-Mathiesen () DESHAW COM (James Mathiesen)]

> Since the patch, programs that are set-uid, call set*uid or set*gid cannot
> be traced and cannot dump core.  (Which upset yet another batch of
> customers so there's an option in Solaris 7 to make set-uid programs
> dump core if the kernel is so configured)

What's the option?  There are a number of times when I would have loved the
ability to enable this temporarily.

One interesting thing about the Solaris implementation of proc(4) is that it
actually does go back and stat the executable when it is checking if it is
readable rather than saving the information during exec().  There are
definitely some minor security implications here, which I haven't thought
about much.

And there's yet another interesting behavior related to this:

        1) Compile an executable such as

                main()
                {
                        sleep(10000);
                }

           And place it on an NFS server.

        2) Run the executable from an NFS client under a non-root uid

        3) On the NFS server unlink the executable (or use another NFS
           client, anything so the inode is gone instead of becoming a
           .nfsXXXX)

        4) On the NFS client try to open /proc/<pid> using the same UID which
           is running the program.  This process will go into a tight loop
           in kernel mode repeatedly stat'ing the executable from step 2
           despite getting ESTALE from the NFS server on each try.  Fortunately
           the operation is interruptable.

Step 4 has to be a proc operation which requires checking the mode of the
executable.  From 2.6 proc(4):

     For security reasons, except for the psinfo, usage, lpsinfo,
     lusage, lwpsinfo, and lwpusage files, which are  world-read-
     able, and except for the super-user, an open of a /proc file
     fails unless both the user-ID and  group-ID  of  the  caller
     match  those  of the traced process and the process's object
     file is readable by the caller.  Except for the  world-read-
     able files just mentioned, files corresponding to setuid and
     setgid processes can be opened only by the super-user.

This appears to still be the case in 2.7.  I actually tried to get Sun
to accept the looping as a bug with 2.5.1, but did not succeed.  I've
never quite gotten the hang of interacting with engineering.

Probably just saving the readable status during exec() would be the
most correct solution.

james