chiark / gitweb /
Regenerated formatted documentation (spec.ps, spec.html).
[userv.git] / spec.html / ch-notes.html
index 74d81cf..e49eb2a 100644 (file)
-<html><head>
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+
+<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>
+
+</head>
+
+<body>
+
+<hr>
+
+[<a href="ch-ipass.html">back</a>]
+ [<a href="index.html#abstract">Abstract</a>]
+ [<a href="index.html#copyright">Copyright Notice</a>]
+ [<a href="index.html#contents">Contents</a>]
+
+<hr>
+
 <h1>
-User service daemon and client specification - chapter 6<br>
+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>
 
+<h2>
+<a name="s-standards">6.1 Standard services and directory management</a>
+</h2>
+
+<p>
 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>
+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
+<p>
+<code>userv</code>-using applications and system services which hide
+<code>userv</code> 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>
+(created by them) <samp>~/.userv/.servdata/<var>service</var></samp>, 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
+<p>
+The use of a dot-directory inside <samp>~/.userv</samp> 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.)
+</p>
+
 <hr>
-<h2><A name="s-reducepriv">
-6.2 Reducing the number of absolutely privileged subsystems
-</A></h2>
 
+<h2>
+<a name="s-reducepriv">6.2 Reducing the number of absolutely privileged subsystems</a>
+</h2>
+
+<p>
 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>
+trusted with the security of the system.
+</p>
 
-Using <kbd>userv</kbd> many of these subsystems no longer need any unusual
-privilege.<P>
+<p>
+Using <code>userv</code> 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
+<p>
+<code>cron</code> and <code>at</code>, <code>lpr</code> and the system's mail transfer
+agent (<code>sendmail</code>, <code>smail</code>, <code>exim</code> or the like) all
 fall into this category.
+</p>
+
 <hr>
-<h2><A name="s-noexcess">
-6.3 Do not give away excessive privilege to <kbd>userv</kbd>-using facilities
-</A></h2>
 
+<h2>
+<a name="s-noexcess">6.3 Do not give away excessive privilege to <code>userv</code>-using facilities</a>
+</h2>
+
+<p>
 There is a danger that people reimplementing the facilities I mention
-above using <kbd>userv</kbd> will discard much of the security benefit by
+above using <code>userv</code> will discard much of the security benefit by
 using a naive implementation technique.  This will become clearer with
-an example:<P>
+an example:
+</p>
 
-Consider the <kbd>lpr</kbd> program.  In current systems this needs to
+<p>
+Consider the <code>lpr</code> 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
+the file in the context of the user, rather than its own.
+</p>
+
+<p>
+A simple-minded approach to converting this scheme to use <code>userv</code>
+might involve giving the printer daemon (the <code>lp</code> user) the
+ability to read the file by allowing them to run <code>cat</code> (or a
+special-purpose file-reading program) as any user.  The <code>lpr</code>
+program would use a <code>userv</code> 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>
+it felt like it.
+</p>
 
+<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>
+user to execute commands as the <code>lp</code> user will give the user the
+ability to read any file on the system.
+</p>
 
+<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
+submission program <code>lpr</code> 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>
+the user's file of things they'd asked to print.
+</p>
 
+<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>
+program can be quite simple.
+</p>
 
-Similar considerations apply to many <kbd>userv</kbd>-based versions of
-facilities which currently run as root.<P>
+<p>
+Similar considerations apply to many <code>userv</code>-based versions of
+facilities which currently run as root.
+</p>
 
+<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
@@ -108,43 +158,68 @@ 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.
+</p>
+
 <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
+<h2>
+<a name="s-notreally">6.4 <code>userv</code> is not a replacement for <code>really</code> and <code>sudo</code></a>
+</h2>
+
+<p>
+<code>userv</code> 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>
+calling and the called program, which is undesirable in this context.
+</p>
 
+<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
+<code>sudo</code><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
+interaction - it can be hard for a <code>userv</code> service program to
 interact with its real caller or the user in question.
+</p>
+
 <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.
+<h2>
+<a name="s-nogeneral">6.5 Don't give access to general-purpose utilities</a>
+</h2>
+
+<p>
+Do not specify general purpose programs like <code>mv</code> or <code>cat</code>
+in <code>execute-</code> directives without careful thought about their
+arguments, and certainly not if <code>no-suppress-args</code> is specified.
 If you do so it will give the caller much more privilige than you
-probably intend.<P>
+probably intend.
+</p>
 
+<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>.
+<code>sudo</code>.
+</p>
+
 <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.62<br>
-Ian Jackson <A href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</A></address>
-</body></html>
+
+[<a href="ch-ipass.html">back</a>]
+ [<a href="index.html#abstract">Abstract</a>]
+ [<a href="index.html#copyright">Copyright Notice</a>]
+ [<a href="index.html#contents">Contents</a>]
+
+<hr>
+
+User service daemon and client specification<br>
+
+<address>
+0.62<br>
+Ian Jackson <a href="mailto:ian@davenant.greenend.org.uk">ian@davenant.greenend.org.uk</a>
+</address>
+
+</body>
+
+</html>
+