Re: RFD: new section ("secure"?)
On Sun, Jan 16, 2000 at 10:51:20AM -0700, Bear Giles wrote:
> 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.
[cut]
> - 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.
1) breaking FHS, because of some random thoughts is bad.
If we are forgetting about FHS, make /sbin symlink to /bin,
finish /share/doc transfer, fix /var/lib or /var/state problems,
and icons locations, get rid of /usr/X11R6/*, and then think about some
random changes like ``secure in /opt, non-secure in /usr''
We have some better-or-worse packaging system to not have to do
such things as one you proposed.
2) packages in section secure will nearly always be parts of some
additional sections (mail, shell, admin, *). This will be better solved
by keywords and package-pool.
3) why to require shadow passwords ?
Reply to: