RFD: new section ("secure"?)
Inspired in part by the relaxation of US crypto export regulations,
I would like to RFD discussion of a new Debian section, possibly
called "secure."
The motivation for this follows:
- many packages support the use of strong crypto. Known examples
include
- cvs
- lprng
- postgresql
- several mail programs (imap, qpopper, fetchmail, others?)
- sudo
- ckermit
- coda (distributed fs)
- amanda (tape backup)
- ssh
- smart card interfaces (coming soon)
This list can be expected to grow to include *all* programs
that use a client/server model, or that require authentication
beyond the "this is a local user" stage.
- Kerberos, and other strong authentication methods, can NOT be
easily via PAM. First, it is easily to get the implementation
horribly wrong, even if you know what you're doing. (All
Kerberos PAM modules that I have examined are horrible security
violations because the author focused on the details instead
of the big picture.) Second, one of the key benefits of strong
crypto is that it allows for strong *mutual* authentication.
This means that CVS will not download updates from a hijacked
CVS server, LPRng will not print to a hijacked print queue, etc.
PAM cannot offer this.
- even if the US allows unlimited access, other countries still
do not allow use of strong crypto and therefore Debian must
not *require* it.
- even if all countries allowed unlimited access, enabling and
verifying the strong crypto in the packages is not a trivial
issue. Despite our hopes from a year ago, enhanced packages
will require more than simply installing a few -dev packages.
- even if all of the packages are modified, many users may prefer
to use the standard packages because they use a different security
model and do not wish to leave in a back door for implementation
of an alternative security model -- one *not* controlled by
the local security administrators.
- finally, if the user does want the strong crypto packages
he will probably want to default to a more secure configuration.
Separate packages allow the cryto packages to specify a tighter
policy by default.
For these reasons, and on the basis of my experience working
with Kerberos-enhanced packages, I would like to submit the following
proposals.
- creation of a new top-level section, possibly called "secure"
to reflect the fact that some of the packages may not involve
any crypto at all -- they could simply have a more secure
default configuration or be compiled to disable certain behaviors.
Examples of the latter are a "password" library which disables
access to accounts without a password, or BSD trust-based
applications that reject wildcard matches in .rhosts.
- all packages listed above, or added to the "secure" section later,
will have "Provides:" and "Replaces:" fields to allow a secure
alternative to replace them without causing dependency problems
or arcane version information. In this case, the secure package
should have a unique name, e.g., "cvs" becomes "kcvs", "lprng"
becomes "klprng."
- the standard installation model should be to use the standard
tools initially, then load the secure packages. The latter
could be handled by a program (the usual approach) or by
installation of a meta-package which in turn installs other
standard packages.
The latter might be the cleanest way to handle policy changes
such as *requiring* shadow passwords by installing a modified
password library that disregards the /etc/passwd field.
- finally, it *might* be wise to install these packages to
/opt (at least the binaries and man pages) instead of /usr.
I've been experimenting with this approach and found it
useful in keeping track of the secure vs. standard material,
although some package tools have an annoying tendency to
ignore all of my attempts to create a well-behaved unofficial
package.
Obviously it's too late to do much with Potato, but a few changes
made today (e.g., recognizing "secure", modifying the control file
of a few packages) will make it far easier to write well-behaved
add-ons during the next year. There will then be sufficient
information for a good design of the permanent solution in 2.3.
In the interrim, all packages in "secure" should be considered
unofficial and installed to /opt instead of /usr. This is
partially due to the expectation that these packages can be
expected to change rapidly as we learn how to create a secure
system out of the pieces, and partially for the secondary
effect of encouraging, by example, this practice by other
unofficial package developers. The final decision on the
placement of secure packages is then deferred until 2.3.
--
Bear Giles
bgiles@coyotesong.com
Reply to: