From owner-freebsd-security Tue Jul 8 08:59:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23848 for security-outgoing; Tue, 8 Jul 1997 08:59:28 -0700 (PDT) Received: from cyrus.watson.org (robert@cyrus.watson.org [207.86.4.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23836 for ; Tue, 8 Jul 1997 08:59:18 -0700 (PDT) Received: from localhost (robert@localhost) by cyrus.watson.org (8.8.5/8.8.5) with SMTP id LAA04771; Tue, 8 Jul 1997 11:58:44 -0400 (EDT) Date: Tue, 8 Jul 1997 11:58:43 -0400 (EDT) From: Robert Watson To: Mark Newton cc: sef@kithrup.com, security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? In-Reply-To: <9707072348.AA21807@communica.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 8 Jul 1997, Mark Newton wrote: > Robert Watson wrote: > > > On a related note, has anyone given any thought to making chroot() a > > user-accessible call? > > Yow. Extremely bad idea. > > However, taking it to the opposite extreme is a good idea. chroot() loses > its usefulness if a process in a "secured" sandbox can conceivably get > root privileges -- Solution: Restrict the chroot() call for *all* processes > that are already chroot()ed. I was familiar with the actual behavior and implementation of chroot with the processes root, but had never really used it for anything, as it tends to be a more-restricted facility. Can the problems with chroot() safely be sumarized in the following categories? 1. Existing libraries and utilities assume that if they attempt to access /etc/spwd.db (or such), they will get these files off of the absolute root. This may not be changeable, as there are a number of environments where this might be appropriate (boot from floppy, but chroot to mfs/mfs, for example -- the mfs/nfs version of the user database should be used, not the floppy version (same with libraries, etc.)) 2. Creation of hard links retains the setuid behavior of the program, as the permissions and ownership of a file are stored in the inode, and a hardlink merely duplicates the reference to the inode (so I can create /tmp/su as a hard link to /usr/sbin/su, assuming they are both on /usr, and retain the suid and ownership.) This has upsides and downsides -- one downside is if I chroot() myself to /tmp, the existing su will suffer from problem 1. The problem here is that I, as a normal user, can create arbitrary references to suid programs (effectively, instances of them) anywhere I can write to on the same file system. /usr/tmp and /tmp are the most common problem in this area. There are other side effects of this behavior -- as a normal user, I can fill up /tmp with files I can't remove (as sticky bit prevents me from removing references to files I don't own.) Additionally, I can hard link /usr/sbin/su (old buggy version) to /usr/tmp/su before an upgrade to fix the bug, and then the upgrade will leave the old version in /usr/tmp/su (I assume it unlinks the /usr/sbin/su version during upgrade?) Programs may assume that by overwriting (unlinking first) the old version of a setuid program, they are disposing of it, but this may not be true since hard links have the same permissions and content (being the same file :). Symlinks don't have the same problem in that they aren't suid (or such), but still cannot be deleted by a regular user if created in a sticky-bit environment. Daily security mails will pick this up, but you probably cannot assume safely that the user couldn't do the link in the morning before the upgrade, and then take advantage of it in the evening? 3. Current chroot() allows you to undo an old chroot(). If chroot were to become a generally useable call (or even if not), chroot() should only be able to move down the hierarchy, not up. This would make it more transparent as far as the caller was concerned -- they would not have ot know if they were already chroot'd. If the entire filesystem is already chroot("/mfsroot"), then an ftpd chroot("/usr/ftp") would chroot effectively to "/mfsroot/usr/ftp", and be allowed because it does not violate a previous chroot? (since I don't chroot(), I don't know the existing behavior here.) Are there any other chroot caveats? Please figve any ignorance as to the current behavior in BSD -- I'm relatively new to the kernel implementation, although have been using and administering BSD-based machines for a number of years. Robert Watson