From owner-freebsd-current Wed Oct 11 10:53:34 2000 Delivered-To: freebsd-current@freebsd.org Received: from smtp02.iafrica.com (smtp02.iafrica.com [196.7.0.140]) by hub.freebsd.org (Postfix) with ESMTP id 5812137B66C; Wed, 11 Oct 2000 10:53:26 -0700 (PDT) Received: from [196.7.18.138] (helo=grimreaper.grondar.za ident=root) by smtp02.iafrica.com with esmtp (Exim 1.92 #1) id 13jQ49-000BNW-00; Wed, 11 Oct 2000 19:53:21 +0200 Received: from grondar.za (mark@localhost [127.0.0.1]) by grimreaper.grondar.za (8.11.1/8.11.1) with ESMTP id e9BHrbq87539; Wed, 11 Oct 2000 19:53:37 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200010111753.e9BHrbq87539@grimreaper.grondar.za> To: Ruslan Ermilov Cc: current@FreeBSD.org Subject: Re: pam.conf and r(logind|shd) References: <20001011192653.B88648@sunbay.com> In-Reply-To: <20001011192653.B88648@sunbay.com> ; from Ruslan Ermilov "Wed, 11 Oct 2000 19:26:53 +0300." Date: Wed, 11 Oct 2000 19:53:37 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am going to nuke the PAM support for rshd and rlogind in -current > tomorrow (local time) if I won't get any objections till that date. Agreed. login(8) is the right "focus" for PAM in this case. M > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > --tjCHc7DPkfUGtrlw > Content-Type: message/rfc822 > Content-Disposition: inline > > Return-Path: > Received: (from ru@localhost) > by whale.sunbay.crimea.ua (8.11.0/8.11.0) id e9AH3em42884; > Tue, 10 Oct 2000 20:03:40 +0300 (EEST) > (envelope-from ru) > Date: Tue, 10 Oct 2000 20:03:40 +0300 > From: Ruslan Ermilov > To: Robert Watson , Mark Murray > Cc: Warner Losh , security-officer@FreeBSD.org > Subject: Re: pam.conf and r(logind|shd) > Message-ID: <20001010200340.B42287@sunbay.com> > References: <20001006204327.A8112@sunbay.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > In-Reply-To: ; from rwatson@FreeBSD.org on Fri, Oct 06, 2000 at 02:28:57PM -0400 > > On Fri, Oct 06, 2000 at 02:28:57PM -0400, Robert Watson wrote: > > > > On Fri, 6 Oct 2000, Ruslan Ermilov wrote: > > > > > On Fri, Oct 06, 2000 at 11:19:37AM -0600, Warner Losh wrote: > > > > In message <20001006201540.B7215@sunbay.com> Ruslan Ermilov writes: > > > > : I've just committed a fix to rlogind(8) to make it compile without -D NO_PAM. > > > > : Now, (in both -current and -stable), to enable rlogind(8) and sshd(8) user > > > > : will have to enable them in both /etc/inetd.conf and /etc/pam.conf. > > > > > > > > I'm not sure that I like changes like this being merged into -stable > > > > so quickly. This change I'm having problems understanding, so I'll > > > > need some time to go look at them and see what I think. > > > > > > > You are (being the Security Officer) don't like the change which > > > doubly-disables r-foo tools?! I can't believe that :-) > > > > The change aspects that are worrying are: > > > > 1) Substantial structural change to the authentication path by moving to > > PAM for r*, and in the -STABLE branch no less. This is a comment based > > on the clarity of the commit message, so I'm not willing to commit > > to more criticism than this, as I haven't read the patches, just the > > commit message. If the code being run is still the same, clearly it > > doesn't make much difference. > > > > 2) Additional (and in my mind, unnecessary) authorization point for r* > > enabling in /etc/pam.conf. Is there a reason why it isn't enough to > > just have the traditional service toggle in inetd.conf? We have > > entries in pam.conf so that numerous default-disabled features are > > enableable without modifying pam.conf, include xdm which isn't even > > in the base source tree. Increasing configuration complexity can > > dramatically increase the risk associated with possible > > misconfigurations as well as operator frustration, rather than improve > > practical security. > > > Actually, I also think that both rlogind(8) and rshd(8) should be PAM-free. > The reasons are: > > 1) rlogind(8) calls login(1) (with -f if user passed .rhosts authentication), > which itself is a PAM-enabled application. Moreover, the current PAM code > in rlogind(8) is broken, if you try something interactive, say pam_unix.so > in /etc/pam.conf for `rshd' entry. > > 2) rshd(8) is not suitable for interactive PAM modules, since it does not > allocate a pty(4). > > Hence, I am asking Mark for approval to remove the PAM bits from rshd, > rlogind, and pam.conf. > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age > > --tjCHc7DPkfUGtrlw-- > -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message