[2433] in Kerberos-V5-bugs
krb5-appl/173: login.krb5 behavior with an accidentally missing keytab
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Sun Nov 10 22:11:07 1996
Resent-From: gnats@rt-11.MIT.EDU (GNATS Management)
Resent-To: krb5-unassigned@RT-11.MIT.EDU
Resent-Reply-To: krb5-bugs@MIT.EDU, mhpower@MIT.EDU
Date: Sun, 10 Nov 96 22:10:27 -0500
From: mhpower@MIT.EDU
Reply-To: mhpower@MIT.EDU
To: krb5-bugs@MIT.EDU
>Number: 173
>Category: krb5-appl
>Synopsis: login.krb5 behavior with an accidentally missing keytab
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sun Nov 10 22:11:01 EST 1996
>Last-Modified:
>Originator: Matt Power
>Organization:
mit
>Release: 1.0-development
>Environment:
System: ULTRIX yaz-pistachio 4.2 0 RISC
Machine: mips
>Description:
The description of verifying the user's ticket-granting ticket
includes the text "If the host/<host> service is unknown
(i.e., the local keytab doesn't have it), let her in." and
"If the rcmd.<host> service is unknown (i.e., the local
srvtab doesn't have it), let her in." I believe it is
important to provide a way to configure login.krb5 such that
the keytab (and srvtab, if appropriate) file must exist.
Otherwise, the security provided through use of the keytab
file may be lost if the keytab file was supposed to exist
but was removed by some mechanism other than an authorized
person explicitly deciding to remove it. For example, the
keytab file might go away during a run of fsck. Also, there
are occasionally security holes in software unrelated to
Kerberos that allow ordinary users to remove files owned by
root, but otherwise don't grant the users root access (e.g.,
this problem exists in some versions of lpr, and in various
other programs that are attempting to delete only certain
files under /tmp/). Because of these two reasons, it's often
not a good idea to disable a security feature on the basis of
finding that a particular file does not exist.
>How-To-Repeat:
Presumably the problem could be examined by simply deleting
or renaming a system's keytab file. If a more realistic
scenario is needed, install unreliable disk hardware or an
appropriately broken version of lpr.
>Fix:
I think the best solution is for the option to require that
the keytab file exists and contains the relevant key. Another
possibility is to require only that the keytab file exists
and has non-zero length. In this latter case, it may be
sufficiently unlikely that the keytab file accidentally has
contents that weren't intended by the system administrator.
>Audit-Trail:
>Unformatted:
