Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Jul 1997 11:58:43 -0400 (EDT)
From:      Robert Watson <robert@cyrus.watson.org>
To:        Mark Newton <newton@communica.com.au>
Cc:        sef@kithrup.com, security@FreeBSD.ORG
Subject:   Re: Security Model/Target for FreeBSD or 4.4?
Message-ID:  <Pine.BSF.3.95q.970708114608.4712B-100000@cyrus.watson.org>
In-Reply-To: <9707072348.AA21807@communica.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970708114608.4712B-100000>