home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / sys5 / r4 / 1179 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.4 KB
  1. Path: sparky!uunet!wupost!uwm.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!ogicse!das-news.harvard.edu!husc-news.harvard.edu!husc8.harvard.edu!maziere1
  2. From: maziere1@husc8.harvard.edu (David Mazieres)
  3. Newsgroups: comp.unix.sys5.r4
  4. Subject: SUID shell script weirdness
  5. Message-ID: <1993Jan8.160453.19117@husc3.harvard.edu>
  6. Date: 8 Jan 93 21:04:52 GMT
  7. Article-I.D.: husc3.1993Jan8.160453.19117
  8. Distribution: world
  9. Organization: Harvard University Science Center
  10. Lines: 72
  11. Nntp-Posting-Host: husc8.harvard.edu
  12.  
  13.  
  14. I have been experiencing an extremely bizarre problem with SETUID shell
  15. scripts on SVR4 (Consensys), and would appreciate any advice.
  16.  
  17. First, the kernel actually allows SETUID shell scripts (without a C
  18. wrapper, that is).  Does this mean the "exec a symbolic link to a
  19. SUID shellscript + quickly change to a different file" bug has been
  20. fixed in SVR4?  If not, how do I disable SUID shell scripts in the
  21. kernel.  I checked the description of all the mtune parameters in
  22. the System Administrator's Guide, but couldn't find anything having
  23. to do with this.
  24.  
  25. Second, and even more disturbing, the plain old "/bin/mkdir" (not
  26. SETUID) appears to be able to do things it is not supposed to be
  27. able to do.  I am running with RSTCHOWN set to 1 in the kernel (i.e.
  28. BSD-style chown and chgrp restrictions).  Now, I quote from the
  29. mkdir (2) man page:
  30.  
  31.      The directory's owner ID is set to the  process's  effective
  32.      user  ID.   The directory's group ID is set to the process's
  33.      effective group ID, or if the SETGID bit  is  set  in  the
  34.      parent  directory,  then  the  group  ID of the directory is
  35.      inherited from the parent.
  36.  
  37. And yet, observe the following behaviour:
  38.  
  39. > id
  40. uid=100(dm) gid=100(oper)
  41. > ls -al sh
  42. -r-sr-xr-x   1 font     oper        63992 Jan  8 12:55 sh
  43. > ./sh
  44. $ id
  45. uid=100(dm) gid=100(oper) euid=108(font)
  46. $ cd /tmp
  47. $ /bin/mkdir suid_bug
  48. $ ls -ald suid_bug
  49. drwxr-xr-x   2 dm       oper          512 Jan  8 15:35 suid_bug
  50. $ /bin/rm -rf suid_bug
  51. rm: Unable to remove directory
  52. Permission denied
  53. $ /usr/local/gnubin/rmdir suid_bug
  54. /usr/local/gnubin/rmdir: suid_bug: Permission denied
  55. $ /bin/rmdir suid_bug
  56. $ /usr/local/gnubin/mkdir suid_bug
  57. $ ls -ald suid_bug
  58. drwxr-xr-x   2 font     oper          512 Jan  8 15:36 suid_bug
  59. $ /bin/rmdir suid_bug
  60. rmdir: suid_bug: Search or write permission needed
  61. $ /bin/rm -rf suid_bug
  62. $ > exit
  63.  
  64. Process shell finished
  65.  
  66. That's right, "/bin/mkdir" and "/bin/rmdir" only seem to work with the
  67. real, rather than effective user id's.  But with RSTCHOWN set to 1,
  68. those programs shouldn't even be allowed to create files with UID's
  69. other than the current EUID.  I looked a the source for the GNU version
  70. of mkdir, and it just uses mkdir(2), which behaves as expected.
  71.  
  72. So, what does the AT&T mkdir(1) use to make it's directories, and why?
  73. (I know it doesn't to a flat out seteuid(getuid()), because I still need
  74. write permission on the parent directory.)  This is really annonying in
  75. SUID shell scripts that need to create temporary directories, as those
  76. scripts cannot create files in the directories they just created.  Should
  77. I just use GNU mkdir, or is there some major security hole that I'm
  78. overlooking?
  79.  
  80. Thanks for any help.  Please reply via E-Mail, and I'll post a summary if
  81. the solution is anything non-trivial.  (Please let me know explicitly if
  82. you would object to my quoting your reply in the follow-up article.)
  83.  
  84. david (maziere1@husc.harvard.edu)
  85.