File: rationale.html

package info (click to toggle)
cvm 0.97-0.1
  • links: PTS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 1,036 kB
  • sloc: ansic: 4,065; sh: 2,758; makefile: 235; sql: 15
file content (74 lines) | stat: -rw-r--r-- 3,262 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
<html>
<body>

<h2><a href="cvm.html">CVM</a></h2>

<h1>CVM Design Rationale</h1>

<h2>Design Rationale</h2>

<dl>

<dt>Single credential type per module. <dd><p>Eliminating the choice
of credential types from the logic required by the modules simplifies
the support code required by those modules.  In fact, it should also
simplify the code required by the invoking code, since the invoker
will necessarily have different handling for reading and parsing
different credential types from a client.  Servers that only handle
one type of credentials do not have to deal with this detail.</p>

<dt>Variable fact list. <dd><p>There is no one list of facts that must
be reported by an authenticator.  This list that is reported may be
extended to include more optional facts.</p>

<dt>Single-byte fact identifiers. <dd><p>Simplifying identifier names
into a single byte greatly simplifies parsing code, without making the
output code any more complex, and without significantly reducing the
range of facts that can be expressed.  It also helps to avoid
enlarging the datagram size, which is important due to the strict
limits on total size (see below).</p>

<dt>No chaining. <dd><p>What was accomplished by chaining with
Courier's authentication modules can be better accomplished through
other means.  If multiple types of authentication for the same
credentials can occur, run seperate services on seperate IPs that use
different CVM modules.  If multiple types of credentials are used,
they will each invoke a seperate CVM module.  This eliminates all of
the coding and design headaches associated with chaining Courier IMAP
authentication modules.</p>

<dt>No execution by the module. <dd><p>With the checkpassword
interface, the authentication module drops root priviledges before
executing the second stage program.  This however greatly reduces or
eliminates the feasability of executing the unpriviledged second stage
program in a chroot environment for additional security.</p>

<dt>Limited input and output size. <dd><p>Limiting the total input and
output and output size to reasonable values eliminates one class of
denial of service attacks by limiting the amount of memory required
for buffers and parsing on both the part of the module and the
invoker.</p>

<dt>512 byte request and response maximum sizes. <dd><p>A single UDP
frame is limited to 512 bytes without introducing serious transmission
reliability problems.  The UDP response also contains a single byte
indicating success/failure that the executable-mode programs transmit
out-of-band through the program's exit code.</p>

<dt>Options for long-running server modules. <dd><p>Long-running
server modules provide a method for transitioning permissions
boundaries (such as requiring EUID 0 to read <tt>/etc/shadow</tt>)
without having to resort to setuid execution, as well as opportunities
for caching of credential information that may otherwise take
significant amounts of time to fetch.</p>

<dt>Options for both UNIX domain and UDP server
modules. <dd><p>Through the standard UNIX permission model, system
administrators can restrict access to UNIX domain servers.
Administrators of clusters can use UDP modules to provide centralized
authentication services.</p>

</dl>

</body>
</html>