From owner-freebsd-security Tue Feb 26 16:21:57 2002 Delivered-To: freebsd-security@freebsd.org Received: from va.cs.wm.edu (va.cs.wm.edu [128.239.2.31]) by hub.freebsd.org (Postfix) with ESMTP id E459337B417 for ; Tue, 26 Feb 2002 16:21:48 -0800 (PST) Received: from dali.cs.wm.edu (dali [128.239.26.26]) by va.cs.wm.edu (8.11.4/8.9.1) with ESMTP id g1R0LZ824075 for ; Tue, 26 Feb 2002 19:21:36 -0500 (EST) Received: (from zvezdan@localhost) by dali.cs.wm.edu (8.11.6/8.9.1) id g1R0LbE22746 for security@FreeBSD.ORG; Tue, 26 Feb 2002 19:21:37 -0500 Date: Tue, 26 Feb 2002 19:21:37 -0500 From: Zvezdan Petkovic To: security@FreeBSD.ORG Subject: Re: Third /tmp location ? (and maybe a fourth too) Message-ID: <20020226192137.A22734@dali.cs.wm.edu> Mail-Followup-To: security@FreeBSD.ORG References: <20020226152847.L25859-100000@roble.com> <3C7C227B.9020100@kpi.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3C7C227B.9020100@kpi.com.au>; from johnsa@kpi.com.au on Wed, Feb 27, 2002 at 11:04:11AM +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Feb 27, 2002 at 11:04:11AM +1100, Andrew Johns wrote: > Roger Marquis wrote: > > >>> File system full errors are typically caused by > >>> unnecessary partitioning. You rarely see them on > >>> single-partition systems. Creating symlinks or > >>> additional tmp directories to avoid the inevitable > >>> drawback of excess partitions is two bads, which don't sum > >>> to a good. Both also violate the KIS principle. > >>> > >> Unfortunately, as demonstrated in another reply, the > >> optimal partition scheme (/, /usr, /var) is preferred over > >> single partition schemes. > >> > > > > Preferred by who? Not by the majority of admins I've worked > > with over the past couple of decades. Neither is there any > > real gain afforded by a read-only /usr. /usr had to be > > partitioned years ago because it wouldn't fit on the root > > disk. With the introduction of 1GB disks there is no longer > > a good reason to partition /usr though some still > > rationalize the practice citing unsubstantiated benefits of > > read-only mounts vs read-only permissions. > > It's called Defense in Depth, IIRC. Rather than "r/o mounts vs > r/o permissions", it should be "r/o mounts AND r/o perms" to > afford the greatest depth, although neither of these methods stop > anything once someone has root - it will just take them that > little bit longer to get around it (even if only seconds - > note:I'm in agreement that it's basically unsubstantiated, > however see below). > system running from CDROM would do the job. A hacker cannot change /usr/bin/passwd runnning from CDROM. > > > > > Creating a partition for /var is also rarely necessary unless > > your applications require partitioning for performance , > > pseudo-quotas, or they need more disk than the root volume > > provides. > > > > I remember once seeing a system fill /var with a runaway process > that crashed overnight. Unfortunately all on one partition. > System emailed support, they dialled in to fix. Their dial-up > password had expired, they were prompted for new one, system > removed passwd file to update, runaway process saw the free space > and immediately filled it: > => nowhere to write new passwd files! > => passwd files empty > => no users could log in. > => no terminals logged in as root (policy), but there were 600 > users already in... > > I had to pull the plug to reboot it. This was for a bank and > they ran for a whole day (bank terminals stay logged into unix > account but with PICK application f/end) without any new logins. > > Having something fill a separately mounted /var would never cause > this problem... > > Just a few cents worth... > Excellent example. But as I said before, there are two irreconcilable shools of thought on this. I tend to be more practical and flexible than dogmatic. Depending on circumstances and requirements, both choices can be good. -- Zvezdan Petkovic http://www.cs.wm.edu/~zvezdan/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message