spec.html/ch-notes.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
   2
   3 <html>
   4
   5 <head>
   6
   7 <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
   8
   9 <title>User service daemon and client specification - Applications and notes on use</title>
  10
  11 </head>
  12
  13 <body>
  14
  15 <a name="ch-notes"></a>
  16 <hr>
  17
  18 [ <a href="ch-ipass.html">previous</a> ]
  19 [ <a href="index.html#contents">Contents</a> ]
  20 [ <a href="ch-intro.html">1</a> ]
  21 [ <a href="ch-client.html">2</a> ]
  22 [ <a href="ch-envir.html">3</a> ]
  23 [ <a href="ch-config.html">4</a> ]
  24 [ <a href="ch-ipass.html">5</a> ]
  25 [ 6 ]
  26 [ <a href="index.html">next</a> ]
  27
  28 <hr>
  29
  30 <h1>
  31 User service daemon and client specification
  32 <br>Chapter 6 - Applications and notes on use
  33 </h1>
  34
  35
  36 <hr>
  37
  38 <a name="s-examples"></a>
  39 <h2>6.1 Examples</h2>
  40
  41 <p>
  42 The companion package, <code>userv-utils</code>, contains a selection of
  43 example services, some of which are useful tools in their own right.  See the
  44 <code>README</code> in its top-level directory for details.
  45
  46 <hr>
  47
  48 <a name="s-standards"></a>
  49 <h2>6.2 Standard services and directory management</h2>
  50
  51 <p>
  52 In later versions of this specification standard service names and interfaces
  53 for common services such as mail delivery and WWW CGI scripts may be specified.
  54
  55 <p>
  56 <code>userv</code>-using applications and system services which hide
  57 <code>userv</code> behind wrapper scripts may need to store information in the
  58 user's filespace to preserve the correct placement of the security perimiters.
  59 Such applications should usually do so in a directory (created by them)
  60 <samp>~/.userv/<var>service</var></samp>, where <var>service</var> is the
  61 service name or application in question.
  62
  63 <p>
  64 If desired, a dot-directory inside <samp>~/.userv</samp> may be used to avoid
  65 the user becoming confused by finding parts of a semi-privileged application's
  66 internal state in their filespace, and/or discourage them from fiddling with
  67 and thus corrupting it.
  68
  69 <p>
  70 However, <code>userv</code> applications should of course not rely for their
  71 global integrity and security on the integrity of the data on the user's side
  72 of the security boundary.
  73
  74 <hr>
  75
  76 <a name="s-reducepriv"></a>
  77 <h2>6.3 Reducing the number of absolutely privileged subsystems</h2>
  78
  79 <p>
  80 Currently most Unix systems have many components which need to run as root,
  81 even though most of their activity does not strictly require it.  This gives
  82 rise to a large and complex body of code which must be trusted with the
  83 security of the system.
  84
  85 <p>
  86 If they were to use <code>userv</code>, many of these subsystems would no
  87 longer need any unusual privilege.
  88
  89 <p>
  90 <code>cron</code> and <code>at</code>, <code>lpr</code> and the system's mail
  91 transfer agent (<code>sendmail</code>, <code>smail</code>, <code>exim</code> or
  92 the like) all fall into this category, though <code>userv</code>-based versions
  93 of these programs are not currently available.
  94
  95 <hr>
  96
  97 <a name="s-noexcess"></a>
  98 <h2>6.4 Do not give away excessive privilege to <code>userv</code>-using facilities</h2>
  99
 100 <p>
 101 There is a danger that people reimplementing the facilities I mention above
 102 using <code>userv</code> will discard much of the security benefit by using a
 103 naive implementation technique.  This will become clearer with an example:
 104
 105 <p>
 106 Consider the <code>lpr</code> program.  In current systems this needs to have
 107 an absolutely privileged component in order to support delayed printing without
 108 copying: when the user queues a file to be printed the filename is stored in
 109 the print queue, rather than a copy of it, and the printer daemon accesses the
 110 file directly when it is ready to print the job.  In order that the user can
 111 print files which are not world-readable the daemon is given root privilege so
 112 that it can open the file in the context of the user, rather than its own.
 113
 114 <p>
 115 A simple-minded approach to converting this scheme to use <code>userv</code>
 116 might involve giving the printer daemon (the <code>lp</code> user) the ability
 117 to read the file by allowing them to run <code>cat</code> (or a special-purpose
 118 file-reading program) as any user.  The <code>lpr</code> program would use a
 119 <code>userv</code> service to store the filename in the printer daemon's
 120 queues, and the daemon would read the file later when it felt like it.
 121
 122 <p>
 123 However, this would allow the printer daemon to read any file on the system,
 124 whether or not someone had asked for it to be printed.  Since many files will
 125 contain passwords and other security-critical information this is nearly as bad
 126 as giving the daemon root access in the first place.  Any security holes in the
 127 print server which allow a user to execute commands as the <code>lp</code> user
 128 will give the user the ability to read any file on the system.
 129
 130 <p>
 131 Instead, it is necessary to keep a record of which files the daemon has been
 132 asked to print <em>outside</em> the control of the print daemon.  This record
 133 could be kept by a new root-privileged component, but this is not necessary:
 134 the record of which files a user has asked to be printed can be kept under the
 135 control of the user in question.  The submission program <code>lpr</code> will
 136 make a record in an area under the user's control before communicating with the
 137 print server, and the print server would be given the ability to run a special
 138 file-reading program which would only allow files to be read which were listed
 139 in the user's file of things they'd asked to print.
 140
 141 <p>
 142 Now security holes in most of the printing system do not critically affect the
 143 security of the entire system: they only allow the attacker to read and
 144 interfere with print jobs.  Bugs in the programs run by the print server to
 145 read users' files (and to remove entries from the list of files when it has
 146 done with them) will still be serious, but this program can be quite simple.
 147
 148 <p>
 149 Similar considerations apply to many <code>userv</code>-based versions of
 150 facilities which currently run as root.
 151
 152 <p>
 153 It is debatable whether the user-controlled state should be kept in the user's
 154 filespace (in dotfiles, say) or kept in a separate area set aside for the
 155 purpose; however, using the user's home directory (and possibly creating a
 156 separate subdirectory of it as a dotfile to contain subsystem state) has fewer
 157 implications for the rest of the system and makes it entirely clear where the
 158 security boundaries lie.
 159
 160 <hr>
 161
 162 <a name="s-notreally"></a>
 163 <h2>6.5 <code>userv</code> can often replace <code>sudo</code>, but not <code>really</code></h2>
 164
 165 <p>
 166 <code>userv</code> is not intended as a general-purpose system administration
 167 tool with which system administrators can execute arbitrary programs like text
 168 editors as root (or other system users) when they need to.  It is unsuitable
 169 for this purpose precisely because it enforces a strong separation between the
 170 calling and the called program, which is undesirable in this context.
 171
 172 <p>
 173 However, its use when restricted to running particular programs in particular
 174 ways is very similar to many common uses of <code>sudo</code>[<a
 175 href="footnotes.html#f2" name="fr2">2</a>].  <code>userv</code> is generally
 176 much better than restricted <code>sudo</code>, because it protects the called
 177 program much more strongly from bad environmental conditions set up by the
 178 caller.  Most programs that one might want to run via restricted
 179 <code>sudo</code>, have not been designed to run in a partially hostile
 180 environment.  <code>userv</code> allows these programs to be run in a safer
 181 environment and should be used instead.
 182
 183 <hr>
 184
 185 <a name="s-stdinerr"></a>
 186 <h2>6.6 Error handling and input streams (eg stdin)</h2>
 187
 188 <p>
 189 When the service program is reading from a file descriptor connected to the
 190 calling side, the fd that the service program refers to a pipe set up by
 191 <code>userv</code> and not to the same object as was presented by the caller.
 192
 193 <p>
 194 Therefore if there is some kind of error it is possible for the service-side fd
 195 to give premature end of file.  If it is important to tell whether all of the
 196 intended data has been received by the service program, the datastream must
 197 contain an explicit end-of-file indication of some kind.
 198
 199 <p>
 200 For example, consider a <code>userv</code> service for submitting a mail
 201 message, where message is supplied on the service's stdin.  However, if the
 202 calling process is interrupted before it has written all of the message, the
 203 service program will get EOF on the message data.  In a naive arrangement this
 204 would cause a half-complete message to be sent.  To prevent this, it is
 205 necessary to adopt some kind of explicit end indication; for example, the end
 206 of the message could be signalled by a dot on a line by itself, and dots
 207 doubled, as in SMTP.  Then the service program would know when the entire
 208 message had been received, and could avoid queueing incomplete messages.
 209
 210 <hr>
 211
 212 <a name="s-nogeneral"></a>
 213 <h2>6.7 Don't give access to general-purpose utilities</h2>
 214
 215 <p>
 216 Do not specify general purpose programs like <code>mv</code> or
 217 <code>cat</code> in <code>execute-</code> directives without careful thought
 218 about their arguments, and certainly not if <code>no-suppress-args</code> is
 219 specified.  If you do so it will give the caller much more privilige than you
 220 probably intend.
 221
 222 <p>
 223 It is a shame that I have to say this here, but inexperienced administrators
 224 have made similar mistakes with programs like <code>sudo</code>.
 225
 226 <hr>
 227
 228 [ <a href="ch-ipass.html">previous</a> ]
 229 [ <a href="index.html#contents">Contents</a> ]
 230 [ <a href="ch-intro.html">1</a> ]
 231 [ <a href="ch-client.html">2</a> ]
 232 [ <a href="ch-envir.html">3</a> ]
 233 [ <a href="ch-config.html">4</a> ]
 234 [ <a href="ch-ipass.html">5</a> ]
 235 [ 6 ]
 236 [ <a href="index.html">next</a> ]
 237
 238 <hr>
 239
 240 <p>
 241 User service daemon and client specification
 242
 243 <address>
 244 1.0.3<br>
 245 Ian Jackson <code><a href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</a></code>
 246 </address>
 247
 248 <hr>
 249
 250 </body>
 251
 252 </html>
 253