From: James Greer (netwk_dude_10@yahoo.com)
Date: Sun Oct 20 2002 - 23:09:43 EDT
Hello All;
Clarification and original question below (and then
summary).
Date: Tue, 15 Oct 2002 07:10:13 -0700 (PDT)
From: "James Greer" <netwk_dude_10@yahoo.com> | This
is Spam | Add to Address Book
Subject: Question Clarification: Neutering .rhosts in
PAM or RBAC?
To: sunmanagers@sunmanagers.org
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
them.
Hope this clears up my situation. Thanks for the
responses so far... will summarize all.
James
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
their
> home directories. Someone suggested that I go in as
> root and make a blank, root owned and 700 .rhosts
file
> in each home directory, but that doesn't help as
they
> 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
anyway.
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
http://www-dev.cites.uiuc.edu/PAM/pam_per_user/"
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
account)
6) chmod the home directory to 3770 (g+s o+s u+rwx
g+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
scripted)
<Brett suggestion off>
Finally, Casper Dik suggested writing your own
pam_rhosts_auth module with notes as follows:
It needs to entry points:
pam_sm_authenticate
get the three pam items:
PAM_USER
PAM_RHOST
PAM_RUSER
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
user)
PAM_AUTH_ERR
rhost/ruser not set
ruser access not allowed
PAM_SUCCESS
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.
James
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:08 EDT