home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0070.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.9 KB  |  54 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <15ibqsINNc3a@ftp.UU.NET> toon@moene.indiv.nluug.nl (Toon Moene) writes:
  4. >Short question: Why is it considered a security risk when people give away  
  5. >their own files (by chown'ing them to someone else) or setuid 'user' their  
  6. >own executables (OK, they have to be careful here) ?
  7.  
  8. The cited excert from Cray did not state that there was a security risk
  9. involved.  In fact, to the contrary it is worse security for a user who
  10. needs to set the SETUID bit on an application to have to be given super-
  11. user privilege than the way UNIX traditionally worked.
  12.  
  13. There would be a security issue if, having set the SETUID bit on an inode,
  14. the user could then change the inode's associated user (owner), but all
  15. UNIX implementations I know of anticipated this and clear the SETUID bit
  16. upon a chown with non-zero EUID (i.e. the superuser can do this but nobody
  17. else can); also of course the SETUID bit cannot be set (except by EUID 0)
  18. on any inode whose associated user doesn't match the EUID of the chmodder.
  19.  
  20. The research branch of UNIX has long prohibited chown by non-zero EUID,
  21. giving as rationale the notion that it would interfere with file quota
  22. subsystems (which didn't exist anyway at the time).  The commercial flavor
  23. of UNIX has long allowed users to chown their files to somebody else,
  24. clearing the SETUID bit in the process, in order to reduce the number of
  25. instances in which superuser permission would be required.
  26.  
  27. I can think of a couple of practical reasons why Cray and/or other POSIX
  28. followers might want to change the traditional UNIX behavior.  One is
  29. that some "layered" POSIX implementations don't have the requisite
  30. underlying support for correct set-UID operation.  There may be
  31. especially tough problems in getting this to work reliably on certain
  32. brain-damaged Network File Systems.  Another probable contributor is the
  33. move toward more secure UNIX-based environments, particularly those
  34. meeting DoD requirements wherein Mandatory Access Controls must be
  35. provided.  A lot of the original IEEE Std 1003.1 was phrased to allow
  36. the success of certain operations to depend on "suitable privileges"
  37. rather than on the traditional EUID 0, specifically to support alternate
  38. (presumably more rigorous) access control mechanisms.  It is not clear
  39. that such more rigorous security mechanisms could coexist (without loss
  40. of security) with the traditional set-UID approach.
  41.  
  42. I must say that in theory, EUID 0 privilege combined with set-UID
  43. execution suffices for rigorous security control; however, it forces
  44. all implementation of security policy to be forced through some
  45. "knothole" using that facility.  (There are numerous examples of this
  46. in practice.  We used it for our huge MUVES project recently.)  Many
  47. people feel that the security policy needs to be more transparent to
  48. applications (i.e. handled by the kernel) than is possible with the
  49. traditional approach.
  50.  
  51.  
  52. Volume-Number: Volume 28, Number 72
  53.  
  54.