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. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
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 <[EMAIL PROTECTED]> Ruslan Ermilov writes: > > > : I've just committed a fix to rlogind(8) to make it compile without -DNO_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, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age
