--- /dev/null
+<html><head>
+<title>User service daemon and client specification - Applications and notes on use</title>
+<link rev=made href="mailto:ian@davenant.greenend.org.uk">
+</head><body>
+<h1>
+User service daemon and client specification - chapter 6<br>
+Applications and notes on use
+</h1>
+<hr>
+<h2><A name="s-standards">
+6.1 Standard services and directory management
+</A></h2>
+
+In later versions of this specification standard service names and
+interfaces for common services such as mail delivery and WWW CGI
+scripts will be specified.<P>
+
+<kbd>userv</kbd>-using applications and system services which hide
+<kbd>userv</kbd> behind wrapper scripts may need to store information in
+the user's filespace to preserve the correct placement of the security
+perimiters. Such applications should usually do so in a directory
+(created by them) <code>~/.userv/.servdata/</code><var>service</var><code></code>, where
+<var>service</var> is the service name or application in question.<P>
+
+The use of a dot-directory inside <code>~/.userv</code> will hopefully avoid
+the user becoming confused by finding parts of a semi-privileged
+application's internal state in their filespace, and or discourage
+them from fiddling with and thus corrupting it. (Note that such
+applications should of course not rely for their global integrity on
+the integrity of the data on the user's side of the security
+boundary.)
+<hr>
+<h2><A name="s-reducepriv">
+6.2 Reducing the number of absolutely privileged subsystems
+</A></h2>
+
+Currently most Unix systems have many components which need to run as
+root, even though most of their activity does not strictly require
+it. This gives rise to a large and complex body of code which must be
+trusted with the security of the system.<P>
+
+Using <kbd>userv</kbd> many of these subsystems no longer need any unusual
+privilege.<P>
+
+<kbd>cron</kbd> and <kbd>at</kbd>, <kbd>lpr</kbd> and the system's mail transfer
+agent (<kbd>sendmail</kbd>, <kbd>smail</kbd>, <kbd>exim</kbd> or the like) all
+fall into this category.
+<hr>
+<h2><A name="s-noexcess">
+6.3 Do not give away excessive privilege to <kbd>userv</kbd>-using facilities
+</A></h2>
+
+There is a danger that people reimplementing the facilities I mention
+above using <kbd>userv</kbd> will discard much of the security benefit by
+using a naive implementation technique. This will become clearer with
+an example:<P>
+
+Consider the <kbd>lpr</kbd> program. In current systems this needs to
+have an absolutely privileged component in order to support delayed
+printing without copying: when the user queues a file to be printed
+the filename is stored in the print queue, rather than a copy of it,
+and the printer daemon accesses the file directly when it is ready to
+print the job. In order that the user can print files which are not
+world-readable the daemon is given root privilege so that it can open
+the file in the context of the user, rather than its own.<P>
+
+A simple-minded approach to converting this scheme to use <kbd>userv</kbd>
+might involve giving the printer daemon (the <kbd>lp</kbd> user) the
+ability to read the file by allowing them to run <kbd>cat</kbd> (or a
+special-purpose file-reading program) as any user. The <kbd>lpr</kbd>
+program would use a <kbd>userv</kbd> service to store the filename in the
+printer daemon's queues, and the daemon would read the file later when
+it felt like it.<P>
+
+However, this would allow the printer daemon to read any file on the
+system, whether or not someone had asked for it to be printed. Since
+many files will contain passwords and other security-critical
+information this is nearly as bad as giving the daemon root access in
+the first place. Any security holes in the print server which allow a
+user to execute commands as the <kbd>lp</kbd> user will give the user the
+ability to read any file on the system.<P>
+
+Instead, it is necessary to keep a record of which files the daemon
+has been asked to print <em>outside</em> the control of the print daemon.
+This record could be kept by a new root-privileged component, but this
+is not necessary: the record of which files a user has asked to be
+printed can be kept under the control of the user in question. The
+submission program <kbd>lpr</kbd> will make a record in an area under the
+user's control before communicating with the print server, and the
+print server would be given the ability to run a special file-reading
+program which would only allow files to be read which were listed in
+the user's file of things they'd asked to print.<P>
+
+Now security holes in most of the printing system do not critically
+affect the security of the entire system: they only allow the attacker
+to read and interfere with print jobs. Bugs in the programs run by the
+print server to read users' files (and to remove entries from the list
+of files when it has done with them) will still be serious, but this
+program can be quite simple.<P>
+
+Similar considerations apply to many <kbd>userv</kbd>-based versions of
+facilities which currently run as root.<P>
+
+It is debatable whether the user-controlled state should be kept in
+the user's filespace (in dotfiles, say) or kept in a separate area set
+aside for the purpose; however, using the user's home directory (and
+probably creating a separate subdirectory of it as a dotfile to
+contain many subsystems' state) has fewer implications for the rest of
+the system and makes it entirely clear where the security boundaries
+lie.
+<hr>
+<h2><A name="s-notreally">
+6.4 <kbd>userv</kbd> is not a replacement for <kbd>really</kbd> and <kbd>sudo</kbd>
+</A></h2>
+
+<kbd>userv</kbd> is not intended as a general-purpose system
+administration tool with which system administrators can execute
+privileged programs when they need to. It is unsuitable for this
+purpose precisely because it enforces a strong separation between the
+calling and the called program, which is undesirable in this context.<P>
+
+Its facilities for restricting activities to running certain programs
+may at first glance seem to provide similar functionality to
+<kbd>sudo</kbd><A href="footnotes.html#2" name="fr2">[2]</A>. However, the
+separation mentioned above is a problem here too, particular for
+interaction - it can be hard for a <kbd>userv</kbd> service program to
+interact with its real caller or the user in question.
+<hr>
+<h2><A name="s-nogeneral">
+6.5 Don't give access to general-purpose utilities
+</A></h2>
+
+Do not specify general purpose programs like <kbd>mv</kbd> or <kbd>cat</kbd>
+in <kbd>execute-</kbd> directives without careful thought about their
+arguments, and certainly not if <kbd>no-suppress-args</kbd> is specified.
+If you do so it will give the caller much more privilige than you
+probably intend.<P>
+
+It is a shame that I have to say this here, but inexperienced
+administrators have made similar mistakes with programs like
+<kbd>sudo</kbd>.
+<hr>
+User service daemon and client specification
+- <A href="index.html#copyright"><kbd>userv</kbd> is Copyright 1996-1999 Ian Jackson.</A>
+<br>
+<A href="index.html#toc">Contents</A>; <A href="index.html#abstract">abstract</A>; <A href="ch-ipass.html">back</A>.
+<br>
+<address>0.61.1<br>
+Ian Jackson <A href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</A></address>
+</body></html>
~ian / userv.git / blobdiff