SUMMARY: Neutering .rhosts in PAM or RBAC?

From: James Greer <>
Date: Sun Oct 20 2002 - 23:09:43 EDT
Hello All;

Clarification and original question below (and then

Date:  Tue, 15 Oct 2002 07:10:13 -0700 (PDT)
From: "James Greer" <> | This
is Spam | Add to Address Book
Subject: Question Clarification: Neutering .rhosts in

Just a note to clarify my original question.  Most of
the suggestions I've gotten have had to do with
killing inetd.conf entries (like rlogin and such) or
otherwise nuking the entire trusted host mechanism.

My problem is that I can't do that.  I'm going through
the usual political fight (which I'm sure many of you
can relate to) over the trusted-host relationships
that  have been in use for so long that they've become
ingrained in our processes and, no matter how
ill-advised, will not go away quickly.

My goal is to stop any more of these from appearing,
while still allowing those in place to function --
with the goal of getting rid of all of them
eventually.  I guess I'm just looking for a granular
way of allowing or disallowing the functionality of
.rhosts files until I can purge the entire system of

Hope this clears up my situation.  Thanks for the
responses so far... will summarize all.


On Mon, 14 Oct 2002, James Greer wrote:

> Hello everyone;
> I'm trying to keep users from being able to open
> trusted host relationships via .rhosts files in
> home directories.  Someone suggested that I go in as
> root and make a blank, root owned and 700 .rhosts
> in each home directory, but that doesn't help as
> can just erase it and create another.
> Is there a way through /etc/pam.conf or through RBAC
> (in Solaris 8) to restrict who can't use trust
> relationships if for one reason or another you can't
> issue a policy forbidding them altogether?  (So that
> .rhosts files will simply not work.)
> Thanks... Will summarize.
> James

A good number of people responded with instructions
for killing the systems' trusted-host mechanism
entirely.  As I said in the original e-mail and the
follow-up clarification, that's not an option.  Thanks

Some people also suggested many variations on the
theme of putting a blank, root-owned .rhosts file in
each user's home directory -- doesnt work.  Some also
mentioned putting a .rhosts file in each user's home
directory linked to a heavily-privileged area -- that
don't work either.    The user seems to have total
control over the contents of their home directories no
matter what crafty things we try to do.  If someone
can offer anything in that area that works, I'd love
to hear it and will pass it along to the list.

In addition:

- Some suggested TCP Wrappers
- Some mentioned putting something in /etc/profile
that nukes .rhosts files
- Others suggested the brute-force method of  sweeping
the system and removing all unauthorized .rhosts file
on a regular basis.
- Someone suggested using ACLs to lock down a sys
admin-planted .rhosts file but I've tried that and the
user's innate rights to their home directory always
seems to allow ACLs to be mitigated.

Ors Tiszay suggested the pam_per_user module "...which
gives you the ability to use different auth. schemes
based on username. You can find it at"

Brett Lymn gave the following interesting suggestion
(thanks for the thorough response, Brett!)

<Brett suggestion on>

1) create a root owned directory .rhosts
2) touch a file into the .rhosts directory so it is
not empty
3) create a group with only the owner of the home
directory in it
4) chgrp the home directory to this group.
5) chown said home directory to be owned by root (or
another system
6) chmod the home directory to 3770 (g+s o+s u+rwx

This should prevent the humble user doing anything
with the .rhosts
directory.  The cannot overwrite it because it is a
directory, they
cannot move it because it does not belong to them,
they cannot remove
it because they don't own it and the directory is not
empty.  The good
thing is that they still have use of their home
directory.  It does
burn gid's though and is a pain to set up (though this
could be 

<Brett suggestion off>

Finally, Casper Dik suggested writing your own
pam_rhosts_auth module with notes as follows:

It needs to entry points:


		get the three pam items:


		when these are all set you can do your
		own ruserok() limiting.

			return - PAM_USER_UNKNOWN
				(PAM_USER item is an invalid user or NULL

					rhost/ruser not set
					ruser access not allowed

					allow access

	pam_sm_setcred() - just return PAM_IGNORE

That's the full wrap-up.  Sounds to me like it's
easier o manage to migrate to SSH to do away with this
problem and, in the meantime, to just erase all but
authorized .rhosts files every five minutes!

Thanks to all who responded.

Y! Web Hosting - Let the expert host your web site
sunmanagers mailing list
Received on Sun Oct 20 23:13:54 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:56 EST