rlogin

[Ray Brewer]

Here is my situation, There is a user account on several of my systems, for argument sakes we will call this user BOB. This BOB account is the admin account for the application which is also called BOB1. A certain group of users will "su" to this account to do application maintenance. We now have a new system that has an application called BOB2 (the BOB1 and BOB2 applications are from the same vendor) that requires the same BOB user account. This new system is not managed by the same group of users. The users that manage BOB1 are concerned that the users that manage BOB2 will attempt to rlogin to the BOB1 systems and gain access to data they are not supposed to have. I know we can set up the inetd.sec file on all of the BOB1 systems to not allow rlogin from the BOB2 system and I know that the .rhosts file for user BOB on the BOB1 systems can be set up to not allow the BOB2 system to login without a password. Does anyone know of a way to prevent this from happening by changing something on the BOB2 system without having to modify all of the BOB1 systems? Sorry this is so long winded but I wanted to make sure I was clear. Thanks for any help!!

[Charles McCary]

Put an empty .rhosts file on the BOB2 system in the BOB account that is owned by root and therefore not updatteable by BOB

[Pete Randall]

Sorry, Charles, but that won't stop them from removing the .rhosts file and replacing it with one of their own design.

:^(
Pete

[Charles McCary]

Pete,

How can they remove a file to which they have no permissions?

[Ray Brewer]

Thanks for the suggestion Charles but I agree they can still remove it. I could set the stickey bit on the users directory but then I would have to own that too so they could not change it. There is one other flaw to this, putting an empty .rhosts on the BOB2 system would stop the BOB1 system from being able to rlogin without a password, what I need is the opposite. I need to stop the BOB user on BOB2 from being able to rlogin to the BOB1 systems.

[Rodney Hills]

Any way you could define each group of users as two different groups. Then you can use netgroups to manage connections via rlogin.

See "man netgroup" for info.

-- Rod Hills

[Bill McNAMARA_1]

Hey Charles,
they can do that if they have write permission on the directory - but in this case that would be baad!

Later,
Bill

[Patrick Wallek · Accepted solution]

For rlogin to function correctly, .rhosts files MUST be owned by the user who's home dir they are in, and must have permission of 400 or 600.

Putting a .rhosts file on BOB2 will have no effect on doing an rlogin from BOB2 to BOB1, though.

Something that you could possibly do though is put a wrapper around rlogin, remsh, etc on BOB2.

You'd first rename rlogin to rloing.real. Then do a script or C program that would do an if statement and if $1 = BOB1 (if the host they are going 2 = BOB1) then display an error message and exit. If they are not going to BOB1, then call the real rlogin.

[Tom Danzig]

On the BOB2 system, you can add the -l option to rlogind to prevent the use of .rhosts:

In /etc/inetd.conf, change:
login stream tcp nowait root /usr/lbin/rlogind rlogind

To:
login stream tcp nowait root /usr/lbin/rlogind rlogind -l

From the rlogind man page:

-l : This option is used to prevent any authentication based on the user's .rhosts file unless the user is logging in as super-user.

[Tom Danzig]

Sorry. BOB2 should be BOB1 in the above

[Shannon Petry]

Just a way to fix the .rhost delete stuffs, as I do this on my secure FTP servers.
Assume BOB1's home dir is /home/bob
chown root /home/bob
touch /home/bob/.rhosts
chmod 400 /home/bob/.rhosts

Now noone but root can delete the .rhosts file, or edit it. I repeat this process for .forward also.
Now, make bob directories in his home that he can work in.
I.E.
mkdir /home/bob/scripts
mkdir /home/bob/work
chown bob /home/bob/*

works like a champ, but may not fix this situation.

Regards,
Shannon