spec.html/ch-notes.html

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