rpartha@cadev4.intel.com (Rajan Parthasarathy ~) (10/15/88)
I noticed a possible problem with the "rlogin" command. Typically
the accounts such as "sys", "news", etc. cannot be logged into since
their /etc/passwd entries have a "*" in the password field. But, over
a network it is possible to login as "sys" or "news" etc.
The following sequence of commands provide the output shown and perform
the operation of logging in as "sys":
{the machine name say is mach_1 and the person logged on now is root}
# su sys
$ whoami
sys
$ rlogin mach_2 -l sys
$ hostname
mach_2
$ whoami
sys
For this to work ofcourse, the /etc/hosts.equiv file must have the entry
"mach_1". This allows someone with root priveleges on one machine to login
to another machine even if he/she does not have a valid account on the
other machine. The question remains as to what kind of implications this
"feature" can have. Are there any potential problems that can be forseen??
I have noticed this feature on some of the BSD derived UNIX versions.
any takers??
cheers
rajan
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation. In no way should the above be taken
to be a statement of Intel.
UUCP:{amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!rpartha
ARPA:rpartha%cadev4.intel.com@relay.cs.net
CSNET:rpartha%cadev4.intel.comchris@mimsy.UUCP (Chris Torek) (10/15/88)
In article <3043@mipos3.intel.com> rpartha@cadev4.intel.com (Rajan Parthasarathy) writes: >I noticed a possible problem with the "rlogin" command. It may be a problem for you; but it is *supposed* to work that way. >Typically the accounts such as "sys", "news", etc. cannot be logged >into since their /etc/passwd entries have a "*" in the password field. >But, over a network it is possible to login as "sys" or "news" etc. ... > > # su sys *Here* is the problem. hosts.equiv gives every account (except root) on machine `remote' access to the account on machine `local' with the same login name. But root on `remote' has access to every account on `remote'; so obviously hosts.equiv gives remote's root access to every account (save root) on `local' as well. >... The question remains as to what kind of implications this "feature" >can have. Are there any potential problems that can be forseen?? If you use hosts.equiv as it is intended, none. Okay (I hear you ask), how is it intended to be used? hosts.equiv names those machines that you yourself administer or otherwise trust completely. It does *not* name machines that you have even the least little bit of uncertainty about. Hence the fact that you can (on machine remote) su to root and then to sys and then rlogin does not bother you at all, because you can (on machine local) su to root and then to sys, which has the same effect anyway. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mjr@vax2.nlm.nih.gov.nlm.nih.gov (Marcus J. Ranum) (10/16/88)
In article <3043@mipos3.intel.com> rpartha@cadev4.UUCP () writes: > > I noticed a possible problem with the "rlogin" command. Typically > the accounts such as "sys", "news", etc. cannot be logged into since > their /etc/passwd entries have a "*" in the password field. But, over > a network it is possible to login as "sys" or "news" etc. I used to change the login shells on sys, bin, etc, to something like /usr/games/fortune, but some versions (or is it all?)(I have seen some that don't) of rshd always execute 'rsh' commands using 'sh -c <command>' instead of the pw->shell field in the password file. I don't recall if 'bin' owns the stuff in /bin anymore - used to, but that always was a pretty open hole, if 'bin' could get onto another system and replace /bin/sh with a trojan horse. Possibilities like that are endless - it's better to just keep people off your network if you don't trust 'em :-) --mjr();
carroll@s.cs.uiuc.edu (10/17/88)
RE : host.equiv
It's a real feature of rlogin that the host.equiv files are not required
to be reciprocal. We used this feature to set up 'master machines' so
that root on a master could get anywhere as root, but root on a normal
lab machine could only get to a subset. E.g., the machines for class A
were all root-eqivalent, and the class B machines were also, but an A
machine couldn't be root on a B machine, and vice versa, while a master
machine could be root on any of them. This way, the TA's for each class
could be given root priviledges without risk to machines for other classes
(so if the TA screwed up, it was his problem, not some one else's).
Meanwhile the lab staff could use the master's to fix things when necessary.
Of course, the master machines were *physically* secured also. If the hacker
can get to the master, your security just evaporated.
Alan M. Carroll "How many danger signs did you ignore?
carroll@s.cs.uiuc.edu How many times had you heard it all before?" - AP&EW
CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carrollbarnett@vdsvax.steinmetz.ge.com (Bruce G. Barnett) (10/17/88)
In article <14006@mimsy.UUCP>, chris@mimsy (Chris Torek) writes: >If you use hosts.equiv as it is intended, none. There is one other use for older 4.2 BSD systems: access to printers. That is, if you want to spool to a printer that is connected to a machine you do not trust, you have a slight problem. Older versions of lpd look at /etc/hosts.equiv to determine access privileges. Therefore on the surface printer access implies rlogin access. Newer systems (4.3bsd, SunOS 4.0, Ultrix 2.0) have /etc/hosts.lpd in addition to hosts.equiv. If you have an older version, you can use emacs to edit /usr/lib/lpd, changing /etc/hosts.equiv to /etc/hosts.print. Question: What is a minimmum password file? I have in the past created a stripped down password file for a workstation I want increased security on. Can a password file be reduced to two users, root and myself? Three? Four? -- Bruce Barnett uunet!steinmetz!barnett