Subject: kern/1279: Severe flaw in current (4.4BSD) security model!
To: None <gnats-bugs@gnats.netbsd.org>
From: None <tls@rek.tjls.com>
List: netbsd-bugs
Date: 07/26/1995 03:19:41
>Number:         1279
>Category:       kern
>Synopsis:       The schg file attribute is rendered ineffective.
>Confidential:   yes
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 26 03:20:01 1995
>Last-Modified:
>Originator:     Thor Lancelot Simon
>Organization:
	
>Release:        Everything since the 4.4BSD security stuff went in at 1.0BETA.
>Environment:
Any machine running the NetBSD-1.0 or -current kernel.
	
System: NetBSD fearsome.tjls.com 1.0A NetBSD 1.0A (FEARSOME) #81: Fri Jul 21 00:52:59 EDT 1995 tls@fearsome.tjls.com:/acct/tls/local-src/sys/arch/i386/compile/FEARSOME i386


>Description:
	It is possible to erase and re-create files which have been marked
	with the 'schg' file flag without bringing the system to single-user
	mode (security level 0).  This renders the 'schg' flag ineffective, and
	essentially negates the 4.4BSD security model.

>How-To-Repeat:
	Type 'ls -i filename' to get the inode number of the file you care to
	replace.  Unmount the filesystem the file resides on.  Clear the file's
	inode with 'clri'.  fsck the filesystem; fsck does not -- and probably
	can not, if clri is to be useful at all -- respect the file flags, and
	will happily erase the file.  Remount the filesystem.  Replace the file.

>Fix:
	There are a number of potential fixes.  Unfortunately, the existence of
        the 'd' device renders a number of these fixes incomplete.
        The ironclad fix is not pleasant.  However, the severity of the bug
	makes a somewhat fascistic fix both more palatable and necessary.

	Part 1 of the fix is to not allow local filesystems to be unmounted
	when running at security level >0.

	Though I notice that in -current one can't run clri on raw devices that
	belong to mounted filesystems, one could use the 'd' device to do this
	instead, figuring out the correct offset on the fly.  This implies
	Part 2 of the fix, which is to disallow writing to the 'd' partition
	of any drive which has a mounted filesystem on any partition.

	Actually, it strikes me that even that's not enough, because most
	partition tables include at least one unused partition ('c') which
	contains the necessary sectors to go mucking about with other, mounted
	partitions' contents.  And lots of translated labels probably contain
	more than one such partition.  So what's actually necessary is to
	disallow writing to *any* partition of any disk which has mounted
	partitions on it.  This is somewhat of a PITA, but it's a necessary
	PITA, and I can't see how it breaks anything; you probably should be
	single-user when using newfs or disklabel or fsck anyway.
>Audit-Trail:
>Unformatted: