Re: RFD: new section ("secure"?)

[Brian May <bam@debian.org>]

>>>>> "Bear" == Bear Giles <bear@coyotesong.com> writes:

    Bear> Inspired in part by the relaxation of US crypto export
    Bear> regulations, I would like to RFD discussion of a new Debian
    Bear> section, possibly called "secure."

I think something like this would be a good idea regardless of export
laws, as security software is being developed outside USA (eg
Heimdal).

    Bear> 	 - cvs - lprng - postgresql - several mail programs
    Bear> (imap, qpopper, fetchmail, others?)  - sudo - ckermit - coda
    Bear> (distributed fs) - amanda (tape backup) - ssh - smart card
    Bear> interfaces (coming soon)

Add openldapd to the list - although currently only alpha versions
support SASL --> Kerberos/Heimdal, and even this is rather
experimental.

    Bear>  - Kerberos, and other strong authentication methods, can
    Bear> NOT be easily via PAM.  First, it is easily to get the

Strongly agreed.

    Bear> implementation horribly wrong, even if you know what you're
    Bear> doing.  (All Kerberos PAM modules that I have examined are
    Bear> horrible security violations because the author focused on
    Bear> the details instead of the big picture.)  Second, one of the
    Bear> key benefits of strong crypto is that it allows for strong
    Bear> *mutual* authentication.  This means that CVS will not
    Bear> download updates from a hijacked CVS server, LPRng will not
    Bear> print to a hijacked print queue, etc.  PAM cannot offer
    Bear> this.

I think PAM (at least nobody has told me otherwise yet) only supports
password authentication. This makes it suitable for initial, local,
logins, either via /bin/login, xdm[1], or whatever.

However, it does not make it suitable for remote authentication.
In fact, doing so opens up a number of security holes:

- kerberos *never* transmits the users password to the server.

- a server that only receives a password, could misuse the users
password, obtain a TGT (ticket granting ticket) from the server, and
have full access to everything the user has.

    Bear>  - creation of a new top-level section, possibly called
    Bear> "secure" to reflect the fact that some of the packages may
    Bear> not involve any crypto at all -- they could simply have a
    Bear> more secure default configuration or be compiled to disable
    Bear> certain behaviors.

Big question: would packages in this new top-level section have the
same source code?

I have created a distribution on master, I hope will be used for
Kerberos packages. Currently there are a number of problems which I
still need to fix, but master also seems to be very unreliable lately,
so it is not very easy...

I think packages that have been compiled against heimdal-lib do not
have problems with US export restrictions, am I correct, or should I
move it to non-us.debian.org?

Use the apt/sources.list line:

deb http://master.debian.org/~bam/ frozen main contrib non-free

I have not been able to get this to work, apt reports connection timed
out errors.

    Bear> In the interrim, all packages in "secure" should be
    Bear> considered unofficial and installed to /opt instead of /usr.
    Bear> This is partially due to the expectation that these packages
    Bear> can be expected to change rapidly as we learn how to create
    Bear> a secure system out of the pieces, and partially for the
    Bear> secondary effect of encouraging, by example, this practice
    Bear> by other unofficial package developers.  The final decision
    Bear> on the placement of secure packages is then deferred until
    Bear> 2.3.

I disagree with this:

- I think that packages should be developed to install properly, so we
can find out right from the start what might break when we do this.

- as a Debian developer, I have limited time, and do not want
to worry too much about possible short time breakages, as I would
have to redo a number of thinks to change the directories.

- installing them under /usr means people are more likely to test it
and give bug reports.

The only exception is openldap, which requires an alpha version.  The
maintainer doesn't think it is suitable for release, and he probably
is right.

Note:

[1] ideally kerberos should be properly supported in X-Windows, so it
is used instead of magic cookie authentication. However, I have heard
the current code is very old and badly needs to be updated.

-- 
Brian May <bam@debian.org>