spec.html/ch-notes.html

   1 <html><head>
   2 <title>User service daemon and client specification - Applications and notes on use</title>
   3 <link rev=made href="mailto:ian@davenant.greenend.org.uk">
   4 </head><body>
   5 <h1>
   6 User service daemon and client specification - chapter 6<br>
   7 Applications and notes on use
   8 </h1>
   9 <hr>
  10 <h2><A name="s-standards">
  11 6.1 Standard services and directory management
  12 </A></h2>
  13
  14 In later versions of this specification standard service names and
  15 interfaces for common services such as mail delivery and WWW CGI
  16 scripts will be specified.<P>
  17
  18 <kbd>userv</kbd>-using applications and system services which hide
  19 <kbd>userv</kbd> behind wrapper scripts may need to store information in
  20 the user's filespace to preserve the correct placement of the security
  21 perimiters.  Such applications should usually do so in a directory
  22 (created by them) <code>~/.userv/.servdata/</code><var>service</var><code></code>, where
  23 <var>service</var> is the service name or application in question.<P>
  24
  25 The use of a dot-directory inside <code>~/.userv</code> will hopefully avoid
  26 the user becoming confused by finding parts of a semi-privileged
  27 application's internal state in their filespace, and or discourage
  28 them from fiddling with and thus corrupting it.  (Note that such
  29 applications should of course not rely for their global integrity on
  30 the integrity of the data on the user's side of the security
  31 boundary.)
  32 <hr>
  33 <h2><A name="s-reducepriv">
  34 6.2 Reducing the number of absolutely privileged subsystems
  35 </A></h2>
  36
  37 Currently most Unix systems have many components which need to run as
  38 root, even though most of their activity does not strictly require
  39 it.  This gives rise to a large and complex body of code which must be
  40 trusted with the security of the system.<P>
  41
  42 Using <kbd>userv</kbd> many of these subsystems no longer need any unusual
  43 privilege.<P>
  44
  45 <kbd>cron</kbd> and <kbd>at</kbd>, <kbd>lpr</kbd> and the system's mail transfer
  46 agent (<kbd>sendmail</kbd>, <kbd>smail</kbd>, <kbd>exim</kbd> or the like) all
  47 fall into this category.
  48 <hr>
  49 <h2><A name="s-noexcess">
  50 6.3 Do not give away excessive privilege to <kbd>userv</kbd>-using facilities
  51 </A></h2>
  52
  53 There is a danger that people reimplementing the facilities I mention
  54 above using <kbd>userv</kbd> will discard much of the security benefit by
  55 using a naive implementation technique.  This will become clearer with
  56 an example:<P>
  57
  58 Consider the <kbd>lpr</kbd> program.  In current systems this needs to
  59 have an absolutely privileged component in order to support delayed
  60 printing without copying: when the user queues a file to be printed
  61 the filename is stored in the print queue, rather than a copy of it,
  62 and the printer daemon accesses the file directly when it is ready to
  63 print the job.  In order that the user can print files which are not
  64 world-readable the daemon is given root privilege so that it can open
  65 the file in the context of the user, rather than its own.<P>
  66
  67 A simple-minded approach to converting this scheme to use <kbd>userv</kbd>
  68 might involve giving the printer daemon (the <kbd>lp</kbd> user) the
  69 ability to read the file by allowing them to run <kbd>cat</kbd> (or a
  70 special-purpose file-reading program) as any user.  The <kbd>lpr</kbd>
  71 program would use a <kbd>userv</kbd> service to store the filename in the
  72 printer daemon's queues, and the daemon would read the file later when
  73 it felt like it.<P>
  74
  75 However, this would allow the printer daemon to read any file on the
  76 system, whether or not someone had asked for it to be printed.  Since
  77 many files will contain passwords and other security-critical
  78 information this is nearly as bad as giving the daemon root access in
  79 the first place.  Any security holes in the print server which allow a
  80 user to execute commands as the <kbd>lp</kbd> user will give the user the
  81 ability to read any file on the system.<P>
  82
  83 Instead, it is necessary to keep a record of which files the daemon
  84 has been asked to print <em>outside</em> the control of the print daemon.
  85 This record could be kept by a new root-privileged component, but this
  86 is not necessary: the record of which files a user has asked to be
  87 printed can be kept under the control of the user in question.  The
  88 submission program <kbd>lpr</kbd> will make a record in an area under the
  89 user's control before communicating with the print server, and the
  90 print server would be given the ability to run a special file-reading
  91 program which would only allow files to be read which were listed in
  92 the user's file of things they'd asked to print.<P>
  93
  94 Now security holes in most of the printing system do not critically
  95 affect the security of the entire system: they only allow the attacker
  96 to read and interfere with print jobs.  Bugs in the programs run by the
  97 print server to read users' files (and to remove entries from the list
  98 of files when it has done with them) will still be serious, but this
  99 program can be quite simple.<P>
 100
 101 Similar considerations apply to many <kbd>userv</kbd>-based versions of
 102 facilities which currently run as root.<P>
 103
 104 It is debatable whether the user-controlled state should be kept in
 105 the user's filespace (in dotfiles, say) or kept in a separate area set
 106 aside for the purpose; however, using the user's home directory (and
 107 probably creating a separate subdirectory of it as a dotfile to
 108 contain many subsystems' state) has fewer implications for the rest of
 109 the system and makes it entirely clear where the security boundaries
 110 lie.
 111 <hr>
 112 <h2><A name="s-notreally">
 113 6.4 <kbd>userv</kbd> is not a replacement for <kbd>really</kbd> and <kbd>sudo</kbd>
 114 </A></h2>
 115
 116 <kbd>userv</kbd> is not intended as a general-purpose system
 117 administration tool with which system administrators can execute
 118 privileged programs when they need to.  It is unsuitable for this
 119 purpose precisely because it enforces a strong separation between the
 120 calling and the called program, which is undesirable in this context.<P>
 121
 122 Its facilities for restricting activities to running certain programs
 123 may at first glance seem to provide similar functionality to
 124 <kbd>sudo</kbd><A href="footnotes.html#2" name="fr2">[2]</A>.  However, the
 125 separation mentioned above is a problem here too, particular for
 126 interaction - it can be hard for a <kbd>userv</kbd> service program to
 127 interact with its real caller or the user in question.
 128 <hr>
 129 <h2><A name="s-nogeneral">
 130 6.5 Don't give access to general-purpose utilities
 131 </A></h2>
 132
 133 Do not specify general purpose programs like <kbd>mv</kbd> or <kbd>cat</kbd>
 134 in <kbd>execute-</kbd> directives without careful thought about their
 135 arguments, and certainly not if <kbd>no-suppress-args</kbd> is specified.
 136 If you do so it will give the caller much more privilige than you
 137 probably intend.<P>
 138
 139 It is a shame that I have to say this here, but inexperienced
 140 administrators have made similar mistakes with programs like
 141 <kbd>sudo</kbd>.
 142 <hr>
 143 User service daemon and client specification
 144 - <A href="index.html#copyright"><kbd>userv</kbd> is Copyright 1996-1999 Ian Jackson.</A>
 145 <br>
 146 <A href="index.html#toc">Contents</A>; <A href="index.html#abstract">abstract</A>; <A href="ch-ipass.html">back</A>.
 147 <br>
 148 <address>0.61.1<br>
 149 Ian Jackson <A href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</A></address>
 150 </body></html>