On Sat, Sep 9, 2023 at 5:34 PM Daniele B. <my2...@has.im> wrote: > Just investigating about /etc/hosts.equiv and ~/.rhosts and I was > quite serious to think that my system doesn't need both of them.... >
I have not used a system in 30 years where /etc/hosts.equiv existed. I deleted my .rhosts when ssh was present on all the systems I had to deal with. I then start to look carefully my /etc and discovered a link > that read like this: > > 0 lrwxrwx--- 1 root wheel 13 Mar 25 17:14 /etc/rmt -> /usr/sbin/rmt > So, 45 years ago, /sbin didn't exist and when "systems" programs were added they were put in /etc. So, when someone decided it would be neat if dump could send its output over an rcmd(3) connection to another machine, the rmt program was put in /etc and dump was told to invoke "/etc/rmt" via rcmd(). Indeed, dump *still does that* in OpenBSD. man rmt: > ... > man rcmd: > ... > SUPERBUG (by myself): > ======== > One can be "tempted" to think to a ruserok() function that hacked can > return always OK (0) and otherwise one can always revert to rcmdsh() > with the help of a "good" rshprog. > I'm sorry, but I don't understand what you're trying to say here. ruserok() is in libc and linked into rmt, so in this case "a ruserok() function that hacked can return always OK" would mean "if you can alter a root owned binary on the target system", which is...boring? I'm here to ask enlightment about the opportunity to define > /etc/hosts.equiv and ~/.rhosts but mainly Short answer: don't. Longer answer: "what problem are you trying to solve?" I suppose OpenSSH still has some hosts.equiv and .rhosts bits, but I trust that Theo periodically attempts to kill them completely and only the "we will sell no wine / until its time" hands of Damien and Darren will measure when they can finally be removed (if I haven't lost track and they're already gone). If there is still support for those in base libc, well, your asking about them may result in them being removed. > if it is still the case (and > why) to have this rmt link in etc. See explanation above. > Last if not first, what is the best > practice to defend myself form BUG and SUPERBUG listed above. > "Don't let untrusted people alter libc on your system" You *do* understand that you are trusting the OpenBSD developers by using OpenBSD, just as you are trusting the FreeBSD developers if you use FreeBSD, and trusting the Linux kernel and glibc and GNU-whatever utils, and systemd, and distro developers if you use a Linux distribution, yes? If you don't trust a community or find its values don't match yours, then find a different community that matches it better, or build your own. Philip Guenther OpenBSD developer
