home *** CD-ROM | disk | FTP | other *** search
/ ftp.cse.unsw.edu.au / 2014.06.ftp.cse.unsw.edu.au.tar / ftp.cse.unsw.edu.au / pub / doc / papers / misc / cs.toronto.edu:programming / setuid.doc < prev    next >
Encoding:
Text File  |  1992-10-18  |  12.1 KB  |  331 lines
  1.  
  2.  
  3.  
  4. SETUID(7)    PUBLIC FILES, TABLES, AND TROFF MACROS     SETUID(7)
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      setuid - checklist for security of setuid programs
  10.  
  11. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  12.      Writing a secure  setuid  (or  setgid)  program  is  tricky.
  13.      There  are  a  number  of possible ways of subverting such a
  14.      program.  The most conspicuous security holes occur  when  a
  15.      setuid  program  is not sufficiently careful to avoid giving
  16.      away access to resources it legitimately  has  the  use  of.
  17.      Most of the other attacks are basically a matter of altering
  18.      the program's environment in unexpected ways and  hoping  it
  19.      will fail in some security-breaching manner.  There are gen-
  20.      erally three categories of environment manipulation: supply-
  21.      ing  a  legal  but unexpected environment that may cause the
  22.      program to directly do  something  insecure,  arranging  for
  23.      error  conditions that the program may not handle correctly,
  24.      and the specialized subcategory of giving the program inade-
  25.      quate resources in hopes that it won't respond properly.
  26.  
  27.      The following are general considerations  of  security  when
  28.      writing a setuid program.
  29.  
  30.      [] The program should run with the weakest userid  possible,
  31.         preferably one used only by itself.  A security hole in a
  32.         setuid program running with  a  highly-privileged  userid
  33.         can  compromise an entire system.  Security-critical pro-
  34.         grams like _p_a_s_s_w_d(1) should always have private  userids,
  35.         to minimize possible damage from penetrations elsewhere.
  36.  
  37.      [] The result of _g_e_t_l_o_g_i_n or _t_t_y_n_a_m_e may  be  wrong  if  the
  38.         descriptors  have  been  meddled with.  There is _n_o fool-
  39.         proof way to determine the controlling  terminal  or  the
  40.         login name (as opposed to uid) on V7.
  41.  
  42.      [] On some systems (not ours), the setuid  bit  may  not  be
  43.         honored if the program is run by _r_o_o_t, so the program may
  44.         find itself running as _r_o_o_t.
  45.  
  46.      [] Programs that attempt to use _c_r_e_a_t for locking  can  foul
  47.         up when run by _r_o_o_t; use of _l_i_n_k is preferred when imple-
  48.         menting locking.  Using _c_h_m_o_d for locking is  an  obvious
  49.         disaster.
  50.  
  51.      [] Breaking an existing lock is very dangerous;  the  break-
  52.         down  of  a  locking  protocol  may be symptomatic of far
  53.         worse problems.  Doing so on the basis of the lock  being
  54.         `old'  is  sometimes  necessary, but programs can run for
  55.         surprising lengths of time on heavily-loaded systems.
  56.  
  57.      [] Care must be taken that user requests for i/o are checked
  58.         for  permissions  using  the  user's permissions, not the
  59.         program's.  Use of _a_c_c_e_s_s is recommended.
  60.  
  61.  
  62.  
  63. Sun Release 4.0        Last change: local                       1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. SETUID(7)    PUBLIC FILES, TABLES, AND TROFF MACROS     SETUID(7)
  71.  
  72.  
  73.  
  74.      [] Programs executed at user request  (e.g.  shell  escapes)
  75.         must not receive the setuid program's permissions; use of
  76.         daughter    processes    and    _s_e_t_u_i_d(_g_e_t_u_i_d())     plus
  77.         _s_e_t_g_i_d(_g_e_t_g_i_d()) after _f_o_r_k but before _e_x_e_c is vital.
  78.  
  79.      [] Similarly, programs executed at  user  request  must  not
  80.         receive  other sensitive resources, notably file descrip-
  81.         tors.  Use of _c_l_o_s_e_a_l_l(3) or close-on-exec  arrangements,
  82.         on systems which have them, is recommended.
  83.  
  84.      [] Programs activated by one user but  handling  traffic  on
  85.         behalf  of  others  (e.g.  daemons)  should  avoid  doing
  86.         _s_e_t_u_i_d(_g_e_t_u_i_d()) or _s_e_t_g_i_d(_g_e_t_g_i_d()), since the  original
  87.         invoker's identity is almost certainly inappropriate.  On
  88.         systems which permit it,  use  of  _s_e_t_u_i_d(_g_e_t_e_u_i_d())  and
  89.         _s_e_t_g_i_d(_g_e_t_e_g_i_d())  is recommended when performing work on
  90.         behalf of the system as opposed to a specific user.
  91.  
  92.      [] There are inherent permission problems when a setuid pro-
  93.         gram  executes  another setuid program, since the permis-
  94.         sions are  not  additive.   Care  should  be  taken  that
  95.         created  files are not owned by the wrong person.  Use of
  96.         _s_e_t_u_i_d(_g_e_t_e_u_i_d()) and its gid counterpart  can  help,  if
  97.         the system allows them.
  98.  
  99.      [] Care should be taken that newly-created files do not have
  100.         the wrong permission or ownership even momentarily.  Per-
  101.         missions should be arranged by using  _u_m_a_s_k  in  advance,
  102.         rather than by creating the file wide-open and then using
  103.         _c_h_m_o_d.  Ownership can get sticky due to  the  limitations
  104.         of  the setuid concept, although using a daughter process
  105.         connected by a pipe can help.
  106.  
  107.      [] Setuid programs should be especially careful about  error
  108.         checking,  and the normal response to a strange situation
  109.         should be termination, rather than an  attempt  to  carry
  110.         on.
  111.  
  112.      The following are ways in which the program may  be  induced
  113.      to carelessly give away its special privileges.
  114.  
  115.      [] The directory the program is started in,  or  directories
  116.         it  may plausibly _c_h_d_i_r to, may contain programs with the
  117.         same names as system programs, placed there in hopes that
  118.         the  program will activate a shell with a permissive PPPPAAAATTTTHHHH
  119.         setting.   PPPPAAAATTTTHHHH  should  _a_l_w_a_y_s  be  standardized  before
  120.         invoking  a  shell  (either  directly  or  via  _p_o_p_e_n  or
  121.         _e_x_e_c_v_p/_e_x_e_c_l_p).
  122.  
  123.      [] Similarly, a bizarre IIIIFFFFSSSS setting may alter the  interpre-
  124.         tation  of a shell command in really strange ways, possi-
  125.         bly causing a user-supplied program to be  invoked.   IIIIFFFFSSSS
  126.  
  127.  
  128.  
  129. Sun Release 4.0        Last change: local                       2
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. SETUID(7)    PUBLIC FILES, TABLES, AND TROFF MACROS     SETUID(7)
  137.  
  138.  
  139.  
  140.         too  should  always  be  standardized  before  invoking a
  141.         shell.  (Our shell does this automatically.)
  142.  
  143.      [] Environment  variables  in  general  cannot  be  trusted.
  144.         Their contents should never be taken for granted.
  145.  
  146.      [] Setuid shell files (on systems which implement such) sim-
  147.         ply  cannot  cope adequately with some of these problems.
  148.         They also have some nasty problems like trying to  run  a
  149.         ._p_r_o_f_i_l_e when run under a suitable name.  They are termi-
  150.         nally insecure, and must be avoided.
  151.  
  152.      [] Relying on the contents of files  placed  in  publically-
  153.         writeable   directories,  such  as  /_t_m_p,  is  a  nearly-
  154.         incurable security problem.  Setuid programs should avoid
  155.         using  /_t_m_p  entirely,  if humanly possible.  The sticky-
  156.         directories modification (sticky bit on for  a  directory
  157.         means  only  owner of a file can remove it) (we have this
  158.         feature) helps, but is not a complete solution.
  159.  
  160.      [] A related problem  is  that  spool  directories,  holding
  161.         information that the program will trust later, must never
  162.         be publically writeable even if the files in  the  direc-
  163.         tory  are  protected.  Among other sinister manipulations
  164.         that can be performed, note  that  on  many  Unixes  (not
  165.         ours),  a  core  dump of a setuid program is owned by the
  166.         program's owner and not by the user running it.
  167.  
  168.      The following are unusual but possible error conditions that
  169.      the  program  should cope with properly (resource-exhaustion
  170.      questions are considered separately, see below).
  171.  
  172.      [] The value of _a_r_g_c might be 0.
  173.  
  174.      [] The setting of the _u_m_a_s_k might not be sensible.   In  any
  175.         case,  it  should be standardized when creating files not
  176.         intended to be owned by the user.
  177.  
  178.      [] One or more of the standard descriptors might be  closed,
  179.         so  that  an  opened  file  might get (say) descriptor 1,
  180.         causing chaos if the program tries to do a _p_r_i_n_t_f.
  181.  
  182.      [] The current directory (or any  of  its  parents)  may  be
  183.         unreadable and unsearchable.  On many systems _p_w_d(1) does
  184.         not run setuid-root, so it can  fail  under  such  condi-
  185.         tions.
  186.  
  187.      [] Descriptors shared by other processes (i.e., any that are
  188.         open  on  startup)  may be manipulated in strange ways by
  189.         said processes.
  190.  
  191.      [] The standard descriptors may refer to  a  terminal  which
  192.  
  193.  
  194.  
  195. Sun Release 4.0        Last change: local                       3
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. SETUID(7)    PUBLIC FILES, TABLES, AND TROFF MACROS     SETUID(7)
  203.  
  204.  
  205.  
  206.         has  a  bizarre  mode  setting, or which cannot be opened
  207.         again, or which gives end-of-file on any read attempt, or
  208.         which cannot be read or written successfully.
  209.  
  210.      [] The process may be hit by  interrupt,  quit,  hangup,  or
  211.         broken-pipe  signals,  singly or in fast succession.  The
  212.         user  may  deliberately  exploit  the   race   conditions
  213.         inherent  in  catching signals; ignoring signals is safe,
  214.         but catching them is not.
  215.  
  216.      [] Although non-keyboard signals cannot be sent by  ordinary
  217.         users  in  V7,  they  may  perhaps  be sent by the system
  218.         authorities (e.g. to indicate that the system is about to
  219.         shut down), so the possibility cannot be ignored.
  220.  
  221.      [] On some systems (not ours) there may be an  _a_l_a_r_m  signal
  222.         pending on startup.
  223.  
  224.      [] The program may have children it did not create.  This is
  225.         normal when the process is part of a pipeline.
  226.  
  227.      [] In some non-V7 systems, users can change  the  ownerships
  228.         of  their  files.   Setuid programs should avoid trusting
  229.         the owner identification of a file.
  230.  
  231.      [] User-supplied arguments and input data  _m_u_s_t  be  checked
  232.         meticulously.   Overly-long  input  stored  in  an  array
  233.         without proper bound checking can easily breach security.
  234.         When  software depends on a file being in a specific for-
  235.         mat, user-supplied data should never be inserted into the
  236.         file  without  being  checked first.  Meticulous checking
  237.         includes allowing for the possibility of non-ASCII  char-
  238.         acters.
  239.  
  240.      [] Temporary files left  in  public  directories  like  /_t_m_p
  241.         might vanish at inconvenient times.
  242.  
  243.      The following are resource-exhaustion possibilities that the
  244.      program should respond properly to.
  245.  
  246.      [] The user might have used up all of his allowed processes,
  247.         so  any  attempt  to create a new one (via _f_o_r_k or _p_o_p_e_n)
  248.         will fail.
  249.  
  250.      [] There might be many files open, exhausting the supply  of
  251.         descriptors.   Running _c_l_o_s_e_a_l_l(3), on systems which have
  252.         it, is recommended.
  253.  
  254.      [] There might be many arguments.
  255.  
  256.      [] The arguments and the environment together might occupy a
  257.         great deal of space.
  258.  
  259.  
  260.  
  261. Sun Release 4.0        Last change: local                       4
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. SETUID(7)    PUBLIC FILES, TABLES, AND TROFF MACROS     SETUID(7)
  269.  
  270.  
  271.  
  272.      Systems which impose other  resource  limitations  can  open
  273.      setuid programs to similar resource-exhaustion attacks.
  274.  
  275.      Setuid programs  which  execute  ordinary  programs  without
  276.      reducing  authority  pass  all the above problems on to such
  277.      unprepared children.  Standardizing the  execution  environ-
  278.      ment is only a partial solution.
  279.  
  280. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  281.      closeall(3), standard(3)
  282.  
  283. HHHHIIIISSSSTTTTOOOORRRRYYYY
  284.      Locally written, although based on outside contributions.
  285.  
  286. BBBBUUUUGGGGSSSS
  287.      The list really is rather long...  and probably incomplete.
  288.  
  289.      Neither the author nor the University of Toronto accepts any
  290.      responsibility  whatever  for  the  use  or  non-use of this
  291.      information.
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327. Sun Release 4.0        Last change: local                       5
  328.  
  329.  
  330.  
  331.