[365] in linux-security and linux-alert archive
.rhosts summary
daemon@ATHENA.MIT.EDU (Olaf Kirch)
Sun Sep 17 13:08:04 1995
From: okir@monad.swb.de (Olaf Kirch)
To: linux-security@tarsier.cv.nrao.edu
Date: Sun, 17 Sep 1995 18:08:36 +0200 (MET DST)
Hi all,
There have been a number of follow-ups to the discussion on how make
sure users don't use rhosts files. To bring this discussion to an end,
here's a summary of the posts. I hope this puts the issue to rest;
please send any comments to the respective posters.
Olaf
------------------------------------------------------------------
Martin Hargreaves had suggested in an earlier message that admins creates
directories named .rhosts, .netrc, etc, and check regularly whether they
have been replace by regular files (or symlinks).
Richard Ellis <ellis@pioneer.uspto.gov>:
: For those listening who may not immediately grasp the subtlety of why this
: example occurs, it is because the ability to change the name of a file is
: controlled by the ownership and permissions on the directory that contains
: the file name, not by the ownership and permissions of the file. Changing a
: file name only involves writing to the directory which contains the name,
: not writing to the file.
:
: In the example above, panzer had write access to the ~/panzer directory, and
: therefore was allowed to change the name of the file, even though the file
: was owned by root.
Jon Hamilton <hamilton@cs.iastate.edu>:
: You're still going to lose if you don't put at least one file that the
: user can't remove in that directory.
[example deleted]
: A much better solution is to get a rshd that you can tell to ignore .rhosts
: files. Not allowing .forward files is a bit anal; again, if you're worried
: about people piping mail to programs, turn it off in sendmail.
Matt <panzer@dhp.com>:
: Comment out rservices out of inetd, the damage is already done. As,
: directories mean nothing also. Another, for some people cryptic, example:
[example shows how a .rhosts directory is renamed, and a file is created
containing `+ +' instead.]
Daniel Pewzner <vegi@eskimo.com>:
: Why not just run rlogind and rshd with -l from inetd.conf. Wouldn't that
: cover it?
Alex Yuriev <alex@bach.cis.temple.edu>:
: One can always turn on a t-bit to prevent users from messing around with
: root's files.
[Note: unfortunately, this does not work, because users can still turn off
the t bit on their home directories.]
------------------------------------------------------------------
Marek Michakiewicz had suggested to re-use the setuid bit on directories
as a flag that tells the kernel not to allow the creation of symlinks
in this directory.
Tomasz Surmacz <ts@papaja.wroc.apk.net>:
: It is [used for something else]. At least on SunOS/Solaris.
: If the directory is set with drwxr-xr-x permissions, all files created
: there are created with System V syntax, ie. the group owner will be the
: same as primary group of the user creating files. If the s bit is set
: (drwxr-sr-x) files are created with the BSD behaviour - ie. the group
: owner of file will be the same as the group owner of the directory.
:
: But it does not work for tmpfs file system (and /tmp is usually
: tmpfs), so maybe it could be used this way?
------------------------------------------------------------------
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger okir@brewhq.swb.de.
