Date: Wed, 11 Oct 2000 14:39:13 -0400 From: Dave Gillham <dagill@unx.sas.com> To: Mark Murray <mark@grondar.za> Cc: current@FreeBSD.org Subject: Re: pam.conf and r(logind|shd) Message-ID: <20001011143913.A8461@unx.sas.com> In-Reply-To: <200010111753.e9BHrbq87539@grimreaper.grondar.za>; from mark@grondar.za on Wed, Oct 11, 2000 at 07:53:37PM %2B0200 References: <20001011192653.B88648@sunbay.com> <200010111753.e9BHrbq87539@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. We currently utilize PAM in rshd to restrict access to certain servers based on local criteria when users attempt to rsh non-interactively (in which, I believe, login(8) is not called). We don't object to PAM being removed, but we would like to see an equivalent mechanism supported. -dave > > > -- > > 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: <ru> > > 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 <ru@FreeBSD.org> > > To: Robert Watson <rwatson@FreeBSD.org>, Mark Murray <markm@FreeBSD.org> > > Cc: Warner Losh <imp@village.org>, security-officer@FreeBSD.org > > Subject: Re: pam.conf and r(logind|shd) > > Message-ID: <20001010200340.B42287@sunbay.com> > > References: <20001006204327.A8112@sunbay.com> <Pine.NEB.3.96L.1001006142405.6 > 5844I-100000@fledge.watson.org> > > Mime-Version: 1.0 > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > User-Agent: Mutt/1.2.5i > > In-Reply-To: <Pine.NEB.3.96L.1001006142405.65844I-100000@fledge.watson.org>; > 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 -- David Gillham, x3835 dagill@unx.sas.com SAS Institue Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001011143913.A8461>