> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:55 PDT