old Solaris Kerberos bug question - kadm applications can not refresh their credentials once they've expired

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

old Solaris Kerberos bug question - kadm applications can not refresh their credentials once they've expired

Neng Xue
Hi,

My name is Neng. I am a college hire working for Oracle Solaris Security
Team. Currently I am re-investigating and trying to understand old
Solaris Kerberos bug fixs to see whether they are still applicable to
latest MIT kerberos code(for our MIT drop-in project). One of them is
the bug fix for "*kadm applications can not refresh their credentials
once they've expired*"

The bug description is as following:
===============================================
The kadmin client applications, such as kadmin and kpropd do not have a
proper mechanism for freshing credentials.  Where refresh in the since
of either recreating the credentials or renewing an existing one.
kadmin clients use a different credentials store (/tmp/ovsec_adm.XXXXXX)
rather than the default credential store as with root and host pricipals
(/tmp/krb5cc_0). The routines that already renew credentials are
currently restricted to host or root princs via get_default_cred() and
the like.

Currently this causes failure for kpropd.  Since clnt_vc() calls are not
refreshing properly nor is it returning error.  Therefore kpropd thinks
that it's getting an update with a sno value of 0.  During the next poll
kpropd sends a sno of 0 and the master has a value > 0.  Therefore the
master says that kpropd needs a full-resync. The slave requests a
full-resync and gets one.  This will have a performance hit on the slave
every 8 hours.
===============================================

The bug fix modified three files: *clnt_door.c*, *clnt_dg.c* and
*clnt_vc.c* in rpc library which I did not see in latest MIT kerberos
repo. But there are similar code pieces appeared in *clnt_udp.c*. So my
question is that are the lastest MIT kerberos code still suffered from
this bug? Or how can I judge whether the bug fix is still applicable?
Thanks a lot in advance!

Best,
Neng


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: old Solaris Kerberos bug question - kadm applications can not refresh their credentials once they've expired

Greg Hudson
On 03/13/2014 04:38 PM, Neng Xue wrote:
> Currently this causes failure for kpropd.  Since clnt_vc() calls are not
> refreshing properly nor is it returning error.  Therefore kpropd thinks
> that it's getting an update with a sno value of 0.
[...]
> So my
> question is that are the lastest MIT kerberos code still suffered from
> this bug? Or how can I judge whether the bug fix is still applicable?

I can't say for sure without setting up a test, but I couldn't find
evidence that this bug affects current MIT krb5.

kpropd calls kadm5_init_with_skey, which gets fresh tickets with the
host keytab and initiates a TCP connection to kadmind.  Then kpropd uses
that connection to make an indefinite number of RPC calls using
clnttcp_call from clnt_tcp.c.  If any of the RPC calls fails (i.e. gets
an error return from clnttcp_call), another kadm5_init_with_skey call is
made to get new tickets and establish a new connection.

With a current kadmind, an RPC call would typically only fail if the TCP
is broken due to a network interruption.  With an old kadmind (before
1.8.3) it could also fail if the ticket used to establish the context
has expired.

As you described the old Solaris bug, kadmind rejects the RPC
authentication when the ticket expires, and instead of returning an
error, the RPC call function returns an all-zeros response structure.
It doesn't look like our clnttcp_call function will do this if it
receives an authentication failure response.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev