Page MenuHomeFreeBSD

Remove redundant pam_rhosts
AbandonedPublic

Authored by cy on Oct 6 2017, 3:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 27 2024, 6:10 PM
Unknown Object (File)
Dec 20 2023, 3:56 AM
Unknown Object (File)
Nov 10 2023, 4:42 AM
Unknown Object (File)
Oct 30 2023, 11:35 PM
Unknown Object (File)
Oct 26 2023, 2:35 PM
Unknown Object (File)
Sep 29 2023, 12:37 AM
Unknown Object (File)
Sep 10 2023, 8:39 PM
Unknown Object (File)
Aug 22 2023, 10:19 AM
Subscribers

Details

Reviewers
bapt
brooks
jhb
allanjude
jlh
des
Group Reviewers
manpages
Summary

With the removal of rcmds recently in rS324351 (D12573), It is proposed we now remove the redundant pam_rhosts.

A port should be created to replace pam_rhosts for any who need it.

Test Plan

make tinderbox.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 11935

Event Timeline

brooks requested changes to this revision.Oct 6 2017, 5:58 PM
brooks added inline comments.
ObsoleteFiles.inc
45

dates are wrong here.

This revision now requires changes to proceed.Oct 6 2017, 5:58 PM

Dag-Erling should probably weigh in as this is a pam change.

Sorry I'm still learning how the whole thing works :-).

As I said in https://reviews.freebsd.org/D12573, it's not obvious to me that pam_rhosts(8) is related to rcmds although I totally understand they were used alongside. But in my understanding pam_rhosts(8) can be used independently of rsh(1)/rlogin(1).

Not a big deal jlh. Rhosts is what made rcmds insecure and other applications that use pam_rhosts are just as insecure. Rcmds BTW are the only applications that used pam_rhosts. They need to go.

cy marked an inline comment as done.

This diff is based on HEAD as of r324368.

ObsoleteFiles.inc
45

I realized I was using an old git tree on my way to $JOB. I will upload a new diff.

I exported pam_rhosts (including history) to github here, https://github.com/cschuber/pam_rhosts.

You assume that applications that use pam_rhosts use only pam_rhosts. That is not necessarily the case. A better option would be to update all relevant man pages to mention that relying on .rhosts or hosts.equiv alone is unsafe, and perhaps also modify pam_rhosts to support alternate path names via module options.

The applications that use pam_rhosts were removed by r324351. What else uses pam_rhosts? Are you suggesting end-user applications?

In theory, anything could use it. OpenSSH still supports rhosts (though it has its own code for it).

True ssh can use rhosts but why would anyone use it? My point is, the rcmds were removed because they were insecure. The main reason they were insecure was rhosts (which is one reason MIT produced Kerberized versions of the same utilities). Not that I disagree, it would have make more sense to remove pam_rhosts before rcmds.

We can abandon this revision and revisit it at some time when ssh no longer uses rhosts (or we as FreeBSD want to desupport it).

The r* utilities were removed because they are unencrypted and send passwords in the clear. The kerberized versions solve the latter issue but not the former (which is a problem if you use su or sudo while logged in with rlogin, for instance).

I don't see OpenSSH dropping support for rhosts / shosts any time soon. It is used as an additional restriction, not as a primary authentication method, so it does not pose a security risk. Other applications may use pam_rhosts in a similar manner. We also have pam_login_access which implements a similar mechanism but stores the policy in the login class rather than a separate file.

BTW, your patch misses several references to rhosts and hosts.equiv in documentation. You should probably also add __warn_references() annotations for rcmd(), rcmd_af() and rcmdsh() in libc, regardless of whether you remove pam_rhosts or not.

So has a consensus been reached finally? I can go either way, although dropping the revision and leaving things as-is is obviously the easiest way ;-).

I don't think there is a consensus. Maybe at some point in the future I or someone else can revisit this. Host (IP address) based authentication is well past its due date.