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