From tillman@seekingfire.com  Wed Mar  2 19:46:53 2005
Return-Path: <tillman@seekingfire.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id F39DE16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  2 Mar 2005 19:46:52 +0000 (GMT)
Received: from mail.seekingfire.com (caliban.rospa.ca [24.72.10.209])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 5132243D31
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  2 Mar 2005 19:46:52 +0000 (GMT)
	(envelope-from tillman@seekingfire.com)
Received: from backforty.seekingfire.prv (backforty.seekingfire.prv [192.168.23.42])
	by mail.seekingfire.com (Postfix) with ESMTP id 85291437
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  2 Mar 2005 13:46:51 -0600 (CST)
Message-Id: <1109792811.0@backforty.seekingfire.prv>
Date: Wed, 2 Mar 2005 13:46:51 -0600
From: "Tillman Hodgson" <tillman@seekingfire.com>
To: "FreeBSD gnats submit" <FreeBSD-gnats-submit@freebsd.org>
Subject: -current behaves differently than 4.X w.r.t rsh from security/krb5 port
X-Send-Pr-Version: gtk-send-pr 0.4.4 
X-GNATS-Notify:

>Number:         78325
>Category:       ports
>Synopsis:       -current behaves differently than 4.X w.r.t rsh from security/krb5 port
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    cy
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Mar 02 19:50:02 GMT 2005
>Closed-Date:    Fri Sep 16 18:04:20 GMT 2005
>Last-Modified:  Fri Sep 16 18:04:20 GMT 2005
>Originator:     Tillman Hodgson
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
>Environment:


System 1: FreeBSD 6.0-CURRENT #0: Mon Jan 24 09:41:28 CST 2005
    tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY

System 2: FreeBSD 6.0-CURRENT #0: Tue Mar  1 16:04:05 CST 2005     toor@thoth.seekingfire.com:/usr/obj/usr/src/sys/THOTH  i386

System 3: FreeBSD 4.10-STABLE #0: Thu Nov 18 12:49:31 CST 2004     toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/ATHENA  i386


>Description:


Note:  I originally posted this problem to freebsd-ports@ on Nov 23 2004, with a followup to current@ on Dec 14 2004. The problem still exists in -current with src from as recent as March 01 2005 so I figured I'd file a PR so that the issue can be properly tracked.

I run a couple of Kerberos realms. in late 2004 I installed some new 5.3R machines and then immediately upgraded them to -current. Cursory testing seemed to show that the MIT Kerberos port (security/krb5) was working correctly. Over time, I've found a regression between it and my older 4.X systems (of which I have only remaining).

While kinit, kdestroy, klist, kerberos telnet and ftp, and other basic Kerberos-enabled tools work correctly, the kerberos rsh client (not the server, it's fine) doesn't work on -current.

Here's a a 4-stable box connecting via rsh to another 4-stable box as well as to a -current box:

[root@athena ~]# rsh -x coyote uname -a
This rsh session is encrypting input/output data transmissions.
FreeBSD coyote.seekingfire.com 4.10-STABLE FreeBSD 4.10-STABLE #0: Thu Nov 18 13:10:32 CST 2004 toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/COYOTE  i386

[root@athena ~]# rsh -x backforty uname -a
This rsh session is encrypting input/output data transmissions.
FreeBSD backforty.seekingfire.prv 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Nov 19 08:03:52 CST 2004 tillman@backforty.seekingfire.prv:/usr/obj/usr/src/sys/BACKFORTY  i386

When I try to connect from the -current box ('backforty' from the example above) outwards to either type of box I get a failure:

$ rsh -x coyote uptime
socket: protocol error or closed connection in circuit setup

$ rsh -x caliban uptime
socket: protocol error or closed connection in circuit setup

(caliban is another -current box, in thsi case a sparc64 one).

The auth.log on the server-side system shows:

Nov 23 15:55:10 athena kshd[4565]: connect second port: Connection refused

Note that all other client Kerberos apps work: I can telnet -x, ftp -x, rlogin, etc to my hearts connect. Only rsh displays this behaviour.

I've confirmed that I'm running the right rsh binary:

$ which rsh
/usr/local/krb5/bin/rsh

And I've confirmed that they're both running up-to-date ports trees and the most current version fo security/krb5. I've confirmed that inetd.conf is set up identically between the 4.X and the -current sysetms for the kshd line.

I've googled for the auth.log message. It seems that the connection "back" for stderr is being denied. By what, I don't know ...  the host backforty isn't running any sort of firewall:

root@backforty# ipfw list
ipfw: getsockopt(IP_FW_GET): Protocol not available
root@backforty# ipfstat -hin
open: No such file or directory
root@backforty# pfctl -s rules
pfctl: /dev/pf: No such file or directory

I've confirmed that this issue exists for every -current box that I've run across (I run 4 myself).

The problem is particularly vexing because Kerberos rsh is commonly used for securing "cluster" type operations (rmt for remote central backups, the clusterit port, central management scripting, etc).



>How-To-Repeat:


Install security/krb5 port (the MIT Kerberos port) on a -current system. Try to use the rsh client that it installs. Compare with the results on a 4.X system.

I have a good working knowledge of Kerberos and I'm willing to do testing across a variety of systems if someone wants to test a potential fix :-)


>Fix:





>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-ports-bugs->cy 
Responsible-Changed-By: vs 
Responsible-Changed-When: Thu Mar 3 16:36:05 GMT 2005 
Responsible-Changed-Why:  
Over to maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=78325 

From: Tillman Hodgson <tillman@seekingfire.com>
To: freebsd-gnats-submit@FreeBSD.org, tillman@seekingfire.com
Cc:  
Subject: Re: ports/78325: -current behaves differently than 4.X w.r.t rsh from security/krb5 port
Date: Fri, 11 Mar 2005 13:40:44 -0600

 Followup:
 
 I've confirmed that the Heimdal port doesn't exhibit this behaviour --
 Kerberos rsh/rshd works fine there. Note that this is the Heimdal port I
 tested, the Heimdal in the base OS doesn't have the Kerberos bits in
 rsh.

From: Cy Schubert <Cy.Schubert@komquats.com>
To: freebsd-gnats-submit@FreeBSD.org, tillman@seekingfire.com
Cc:  
Subject: Re: ports/78325: -current behaves differently than 4.X w.r.t rsh 
 from security/krb5 port
Date: Fri, 11 Mar 2005 12:19:01 -0800

 I've been tracking this since December. No fix yet though. I have noticed 
 that the server attempts to connect to a port on the client that is not (or 
 no longer) open.
 
 
 Cheers,
 Cy Schubert <Cy.Schubert@komquats.com>
 Web:  http://www.komquats.com and http://www.bcbodybuilder.com
 FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
 BC Government:  <Cy.Schubert@gems8.gov.bc.ca>
 
     "Lift long enough and I believe arrogance is replaced by
     humility and fear by courage and selfishness by generosity
     and rudeness by compassion and caring."
         -- Dave Draper
 
 
 

From: Tillman Hodgson <tillman@seekingfire.com>
To: Cy Schubert <Cy.Schubert@spqr.komquats.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: ports/78325: -current behaves differently than 4.X w.r.t rsh from security/krb5 port
Date: Fri, 11 Mar 2005 15:08:17 -0600

 On Fri, Mar 11, 2005 at 12:19:01PM -0800, Cy Schubert wrote:
 > I've been tracking this since December. No fix yet though. I have noticed 
 > that the server attempts to connect to a port on the client that is not (or 
 > no longer) open.
 
 Thanks for tracking this, Cy.
 
 My workaround in the meantime has been to install MIT krb5 to
 /usr/local/krb5 and install the Heimdal port to /usr/local ... and I'm
 using Heimdal solely for rshd. I'd like to be able to jettison one of
 the redundant ports.
 
 Playing with Heimdal in conjunction with MIT and trying all the
 combinations gives the following results .,.
 
 
 FreeBSD -current Heimdal port client to FreeBSD 4.x MIT kshd:
 $ /usr/local/bin/rsh athena uptime
  2:47PM  up 82 days, 22:38, 4 users, load averages: 0.00, 0.00, 0.05
 
 FreeBSD -current Heimdal port client to FreeBSD 4.x MIT kshd (with encryption):
 $ /usr/local/bin/rsh -x athena uptime
 rsh: decrypting data: Decrypt integrity check failed
 
 FreeBSD -current Heimdal port client to FreeBSD -current Heimdal port rshd:
 $ /usr/local/bin/rsh thoth uptime
  2:53PM  up 9 days,  3:22, 3 users, load averages: 0.03, 0.07, 0.07
 
 FreeBSD -current Heimdal port client to FreeBSD -current Heimdal port rshd
 (with encryption):
 $ /usr/local/bin/rsh -x thoth uptime
  2:53PM  up 9 days,  3:23, 3 users, load averages: 0.01, 0.06, 0.07
 
 FreeBSD 4.x MIT port client to FreeBSD 4.x MIT kshd:
 [root@athena ~]# rsh athena uptime
  2:48PM  up 82 days, 22:39, 4 users, load averages: 0.00, 0.00, 0.04
 
 FreeBSD 4.x MIT port client to FreeBSD 4.x MIT kshd (with encryption):
 [root@athena ~]# rsh athena -x uptime
 This rsh session is encrypting input/output data transmissions.
  2:50PM  up 82 days, 22:42, 4 users, load averages: 0.01, 0.00, 0.03
 
 FreeBSD 5.x MIT port client to FreeBSD 4.x MIT kshd:
 $ /usr/local/krb5/bin/rsh athena uptime
 socket: protocol error or closed connection in circuit setup
 
 FreeBSD 5.x MIT port client to FreeBSD 4.x MIT kshd (using encryption):
 $ /usr/local/krb5/bin/rsh -x athena uptime
 socket: protocol error or closed connection in circuit setup
 
 
 So aside from the MIT on 5.x -> anything rsh problems, there also
 appears to be an encrypted rsh problem (`rsh -x`) between Heimdal and
 MIT (regardless of FreeBSD version). Since i only have 1 FreeBSD 4.x
 host, I've just been ignoring that problem.
 
 I took some tcpdumps of working a Heimdal on 5.x to Heimdal on 5.x rsh
 connection and a non-working MIT connection. If they'd be helpful, you
 can find them at
 http://www.seekingfire.com/projects/kerberos/tmp/tcpdumps.html. I can
 also make some ktrace information available if you'd find that useful.
 
 -T
 
 
 -- 
 ``These days, thinking someone is out to get you isn't paranoia, it's
   reality.  Lots of people are out to get you.  Paranoia is thinking
   they're all conspiring together.''
     -- Unknown
State-Changed-From-To: open->closed 
State-Changed-By: cy 
State-Changed-When: Fri Sep 16 18:02:29 GMT 2005 
State-Changed-Why:  
As of the latest 5-STABLE and 6-CURRENT, this is no longer a problem. Closing.  

http://www.freebsd.org/cgi/query-pr.cgi?pr=78325 
>Unformatted:
