[989] in Kerberos_V5_Development
stability of v5 clients and effort required to back-port changes
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Feb 1 15:14:51 1996
Date: Thu, 1 Feb 1996 15:14:33 -0500
From: Sam Hartman <hartmans@MIT.EDU>
To: kcr@MIT.EDU, mhbraun@MIT.EDU
Cc: krbdev@MIT.EDU
In response to a question from Matt, I'm attempted to describe
the stability of the current V5 clients and host services and
comparing this to the work required to back-port the checksumming to
v4 clients.
The clients in the appl directory are fairly unstable in terms
of frequency of code changes. I have been working on them a lot
recently, and I believe a few other people have also checked in
changes.
however, these changes have not really effected the core
functionality of the clients. I have been using krlogind and krshd
from krb5 on tertius since October, and have been using exclusively
krb5 on my laptop since the beginning of IAP. Judging from comments
from the newsgroup, the type of changes that have been made over the
past few months, and my personal expierience, both krlogind and krshd
are stable enough that they are likely to work well under normal
operation. In particular, the krshd appears quite stable; up until
recently, the only change I had made to krshd was to fix its wtmp
handling.
Naturally, I am less sure of the stability of my recent
changes to implement checksumming and to allow krshd to be told to
require encryption be turned on. I have attempted to try
interoperability testing, and know the following combinations of
hardware/OS appear to work fairly well:
* AIX -> Solaris|NetBSD/i386|Linux|SunOS
* Solaris->Sunos|Ultrix|AIX
* Linux -> Solaris|AIX|NetBSD/i386
* SunOS -> SunOS|Solaris
In terms of changes I have recently made that would have to be
It is possible to make most of my recent changes to the V4
clients and servers. I would presume that you probably don't want to
do enough work to implement a V4 replay cache, or to implement rsh
encryption. This would mean:
1) While you could easily integrity-check a command line, you could
not protect the data going over rsh's standard input or output. This
opens up a mildly interesting substitution attack with rcp if you
happen to send more than one file in five minutes; it would be
possible to replay the encrypted file stream with a different command
line than it was originally associated with.
2) Command lines can be repeated, possibly with different data.
3) An authenticator can be reused to open an additional eklogin
session; this isn't all that useful because you won't know what the
key is, so you can't send data that will be accepted by eklogind
unless you do a complete session replay.
I.E. If you back port changes to v4, you would still have to
think about the potential vulnerabilities associated with running a
particular command line with different standard input. For example,
even with checksums, the command:
rsh hostname -l root \( cd destdir\; tar xf - . \)
would be a bad idea, both because you don't have encryption and
because it allow me to replace almost any file on the target system
within the next five minutes. This type of attack requires encryption
or at least integrity checking in the rsh to defend against. (It is
also made much more difficutly by a replay cache)
Anyway, here is a quick summary of what I did; I'll append the
last few months of Changelog entries at the end; they are somewhat
more detailed.
* Use the authenticator checksum in rsh to store a checksum of the
destination port, command line and target user.
* Check this checksum on the remote end, optionally disallowing
connections that do not include a checksum.
* Have rlogin checksum the destination port, terminal type and target
user.
(I checksum the terminal type because it is sent in the command line
slot, and
the client code is shared between rlogin and rsh)
* Have krlogind verify the checksum.
* Have rcp use rsh -x instead of built in encryption. Since you can't
do that, you'd need to have rcp checksum something so the
authenticators it produces cannot be used to start an rsh connection.
Thu Feb 1 00:09:13 1996 Sam Hartman <hartmans@tertius.mit.edu>
* rcp.M: Fix typo.
* krcp.c (des_write): If rcp tries to write to stdin, redirect it
to stdout. That way it works with pipes; the right thing is for
rcp to not try and do this, but introducing remread and remwrite
as variables is significantly more work for only slightly better
code.
(main): Use rsh encryption; not user-to-user. Note that we still
support the answer_auth mechanism for incoming connections
so older clients work, but this is depricated.
(send_auth): expunged with pleasure; answer_auth should go in a
a version or two.
Wed Jan 31 16:24:50 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krsh.c (main): Print SECURE_MESSAGE when appropriate.
* krshd.c (doit): Fork and handle pipes either if stderr signal
processing is enabled *or* encryption is enabled. Rsh always
enables stderr, but rcp won't.
(SECURE_MESSAGE): Moving to client where it belongs, so the stderr
lchannel doesn't get corrupted for rcp. Besides, the client can determine if it is talking to a tty and only print this message to a tty.
* krlogind.c (recvauth): Pas ccache to rd_and_store_for_creds
* krshd.c (recvauth): Pass address of ccache to rd_and_store_for_creds
(ccache): new global variable.
(cleanup): Destroy ccache if we have one.
(doit): Destroy cache on normal terination.
* forward.c (rd_and_store_for_creds): Take a pointer to a ccache;
we should provide the caller with a way of destroying forwarded
credentials.
Tue Jan 30 17:56:49 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krshd.c (envinit): Expand to have space KRB5_CCNAME
(doit): Put krb5_ccname at the end of envinit; this is
handled differently that other variables, because TZ may or may not
beset, so our position cannot be fixed.
Sat Jan 27 18:40:31 1996 Sam Hartman <hartmans@tertius.mit.edu>
* kcmd.c (kcmd): We no longer need F_SETOWN as nothing in appl/bsd
handles oob data with signals any more.
Fri Jan 26 00:37:23 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krlogin.c (endif
):
(reader): Deal with exceptions even while writing.
(reader): Fix bogus select bug; actually select on writing
Wed Jan 24 00:34:42 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krlogind.M krshd.M: Update to document new options.
* Makefile.in (install): Install as kshd and klogind not krshd and
krlogind.
* krshd.c (main): Use krlogind-style options (-54kce)
* krlogind.c (main): Change option parsing to support new format.
(do_krb_login): Use auth_ok and auth_sent masks instead of passed_*
Tue Jan 23 18:10:55 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krshd.c (recvauth): Use the correct username in strlen call for
allocating chksumbuf.
* krlogind.c (recvauth): Code to copy checksum verification code.
Mon Jan 22 15:14:11 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krshd.c (recvauth): Update to expect port in checksum.
* kcmd.c (kcmd): Include port in string of checksumed data to
distinguish between encrypted and unencrypted rlogin.
Mon Jan 22 18:14:05 1996 Ezra Peisach <epeisach@kangaroo.mit.edu>
* krcp.c: Use KRB5_STDARG_P.
* configure.in: Add KRB5_CHECK_PROTOS for prototyps definitions.
Fri Jan 19 10:45:29 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krshd.c (recvauth): Verify checksum against command line and remote user.
(recvauth): Fix accidental memory leak with authenticator and fix
include correct username in checksum
* kcmd.c: Send authenticator with checksum of command line and remote user.
* krlogin.c (des_read): Return 0 or -1 on close/error respectively.
Wed Jan 17 15:14:33 1996 Sam Hartman <hartmans@tertius.mit.edu>
* krlogin.c ((reader): Use select to find out-of-band data, not signals.
(oob): No longer a signal handler; just a function.
(writer): get rid of copytochild setup as sigurg no longer needed
(main): Don't block SIGURG
* configure.in : Include sys/time.h check
--Sam
