Subject: Re: Guest setup : Overwrite .rhosts .forward files.

From: [email-masked] (William L. Sebok)
Date: Tue, 24 Jun 1997 13:48:11 -0400 (EDT)

On Tue, 24 Jun 1997, Michael Brennen wrote:

> To delete a file, write permission is needed to the parent directory,
> not the file itself. 

Artur Pydo <[email-masked]> replied: 
> It sounds strange to me. In Unix world, to delete a file you must be owner
> of the file or must have write access on it.
> In any case a user may delete a file owned by root with read-only access.

Not true: the behavior of Unix is and has been (at least since Version 6 on
the PDP 11) that to delete a file write permission on the directory containing
the file is sufficient.

The is an exception: on some Unix systems, such as SunOS 4.X and Solaris 2.X
from Sun, if the sticky bit is set on the directory then a file in that
directory can ownly be removed if the user owns the file, the user owns the
directory, the file is writable by the user, or the user is a privileged user.

Bill Sebok      Computer Software Manager, Univ. of Maryland, Astronomy
	Internet: [email-masked]	URL: http://www.astro.umd.edu/~wls/

---

From: Jim Dennis <[email-masked]>
Date: Tue, 24 Jun 1997 14:25:23 -0700

>> It sounds strange to me. In Unix world, to delete a file you must 
>> be owner of the file or must have write access on it.
> Not true: the behavior of Unix is and has been (at least since 
> Version 6 on the PDP 11) that to delete a file write permission 
> on the directory containing the file is sufficient.
> 
> The is an exception: on some Unix systems, such as SunOS 4.X and
> Solaris 2.X from Sun, if the sticky bit is set on the directory then
> a file in that directory can ownly be removed if the user owns the
> file, the user owns the directory, the file is writable by the user,
> or the user is a privileged user.
>

	Bill,

	The semantics of the sticky bit on the directory isn't 
	quite as you describe.

	If a directory is 'chmod 1777' (for example) -- to set
	the sticky bit (NOT THE SGID/SUID bits) then files created
	in that directory can only be removed by their owner (or 
	root, of course).  Anyone with with write access to the file
	can truncate it or overwrite it -- but only the owner can 
	remove the link. 

	I'm no Unix historian but I think this feature was added
	to BSD variants first.  SunOS was BSD derived.  However
	Linux and Solaris (each considered to be a SysV "dialect")
	recognize it.  Linux, being an independently developed
	kernel, is a blend of BSD and SysV features -- and most of the
	utilities are GNU -- which lean heavily toward BSD features.
	Solaris probably implements this support to provide better
	backward compatibility.

	(Personally I think most of the good BSDisms have been 
	adopted by most of the modern SysV systems at this point 
	-- but with over 600 versions and variants of Unix out 
	there gathering statistics to support this claim would 
	be a major task.  First we'd spend a month or two defining
	BSDisms, "good BSDisms," and "modern").

	The confusion is simple:  a directory entry is a reference
	to an inode -- a link.  If you have write access to a directory
	you can unlink that file from that directory.  This doesn't 
	affect the file directly.  If there are any other links
	(hard links) to the file it only effects the reference count
	in the inode.  So the permissions on a directory determine
	who can add, modify or remove the links it contains.

	The ownership and permissions of the file (or directory) are 
	contained in it's inode.  We "think" of them as being part of
	the directory entry because 'ls' and 'find' show them to us
	in that context.  However the directory only contains the
	name and the inode information.  All of the ownership, permissions,
	dates, sizes, etc are contained in the inode (along with pointers
	to the first ? data blocks and possibly pointers to the first ?
	"extents" which are other inodes which point to more data blocks).

	Thus anyone with write access to a directory can create a 
	link to any inode on the same filesystem.  They can do this
	even if they don't have any access to any of the existing 
	links (i.e. they don't have read access to any of the directories
	which contain links) -- if they want to get it an write the 
	the code themselves -- and they can guess (watch over someone's
	should when they type 'ls -i') what the inode is.  This doesn't
	give them access to the file -- just a pointer to it.
	
	In recent BSD systems (including BSDI/OS and (Free|Net|Open)BSD)
	there is a chflags command that allows one to set a file to 
	"immutable" (actually they have 'uchg' and 'schg' flags for 
	different sorts of 'immutability')  It's also possible to make
	files "append-only."  

	Quite unrelated to that BSD systems have a feature called 
	"securelevel."  If you use the 'sysctl' command to set 
	securelevel to a specific non-zero value (1 or 2) you get 
	specific limitations -- which include the feature that no 
	flags can be changed on files.  "Securelevel" is a one way
	trip.  Once the system is "secured" it can only be rendered 
	back to securelevel 0 (allow filesystem to be mounted, unmounded
	or remounted, file flags to be changed, modules to be loaded,
	or certain sorts of access to kmem and some devices) by a
	shutdown.  (Someone else on this list who mentioned the 
	'chflags' command seemed to misrepresent this).

	In Linux, when using the 'ext2' filesystem there is the 
	'chattr' command to set "attributes" on files.  These are 
	basically the same as the BSD ufs flags -- there are minor
	differences in details but the basics "immutable," and 
	"append-only" are there.  The Linux 'ext2' fs also presages
	some features like "secure delete" (any file with this attribute
	set will be overwritten by several passes of 1's, 0's and 
	random binary upon removal), and "compressed" (to allow 
	filesystem transparent compression of individual files).
	They may even include some encryption features or "monitor"
	file objects (see the HURD's "watchdog" filesystem objects
	for comparison) in future versions.

	Linux is just now (2.1.x) adding the securelevel feature.

	In either case an immutable file can not be modified --
	not even by its owner.  In addition *no* hard links to 
	such a file can be made, changed or removed -- since that
	would change the reference count in the inode -- which 
	garners an "operation not permitted."

	Another exception to this rule is if the filesystem
	in which the directory exists is mounted read-only.

	Finally there are several forms of Unix (AIX and HP-UX
	at least) that support access control lists (ACL's).
	I'd like to know more about those if anyone could point
	me to a ten-minute administrator's reference.

	So, in summary:

		Manipulation of directory entries depends on 
		the ownership and permissions of the directory.

		Manipulation of file contents and status depends
		on the ownership and permissions of the inode.

		Manipulation of directory entries may affect the
		reference (link) count and possibly some of the 
		date fields in an inode -- even if the user doing
		this has no rights to the file.

		Any un-open inode whose link count is zero is
		reclaimed by the systme -- the file's data blocks
		are returned to the free list, and the inode is 
		marked as "available"

		(We won't discuss the case of an open file with
		a link count of zero).

		The sticky bit is usually meaningless on files in
		modern Unix variants (since the caching algorithms
		generally ignore this "hint" about which data to
		keep in "core").

		The sticky bit on directories means that only the
		owner (and root) of a given entry can remove it.
		This is reasonably widespread -- but not universal.

		Some forms of Unix support filesystem specific 
		"flags" or "attributes" which allow one to make files
		immutable.  These will not allow any normal operation by
		any users (including root) to modify the file's contents
		or inode.  Creating or removing links requires
		modifying the inode's link count field.  (Some systems
		might allow a tricky programmer to rename a link -- but
		the normal 'mv' command won't work on Linux or FreeBSD).

		Most forms of Unix support a read-only mounting option.
		Some have added features to do "union" or "loopback" or
		"overlay" mounting (such that filesystem that you've 
		mounted read-write might be "remounted" at some other
		mount point with different options).  (I'd also like to
		know more about the various implementations of these).

		Some forms of Unix support ACL's for finer granularity
		of access controls.

	In response to the original problem:

	Almost all forms to Unix support a chroot() call. All forms
	of rshd/rlogind that I know of look for .rhosts in the 
	user's home directory.  You can create a special inetd
	entry that does a chroot (8) an launches the ftpd inside of
	your chroot jail.  The authentication is then done on the
	passwd (and possibly the shadow) file inside of that jail.
	Thus you can concoct a guest system where guests can't 
	create .rhosts files that will have any effect.

	You can also use the guestgroups feature of wu-ftpd to 
	do selective chroot (using the 
		/wherever/chroot/./relative-tochroot/home
	syntax in the /etc/passwd file).  It seems that my
	tests showed that rlogind and rshd would not follow that
	sort of path to a .rhosts file (on a Red Hat Linux system --
	circa 4.0).  Also you can use the pathfilter? directive 
	to prevent the .rhosts and .forward problems.

	Personally I'm hoping that PAM will offer less baroque --
	easier to teach, explain and audit methods for limiting
	users to specific services under Unix.  The problem is 
	not new -- and it's shameful how long we've tolerated it.

--
Jim Dennis,                                [email-masked]
Proprietor,                          [email-masked]
Starshine Technical Services              http://www.starshine.org

        PGP  1024/2ABF03B1 Jim Dennis <[email-masked]>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A