From owner-freebsd-security@FreeBSD.ORG  Thu Nov  9 15:14:55 2006
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
X-Original-To: freebsd-security@freebsd.org
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0D5EC16A415
	for <freebsd-security@freebsd.org>;
	Thu,  9 Nov 2006 15:14:55 +0000 (UTC)
	(envelope-from freebsd-security-local@be-well.ilk.org)
Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net
	[69.17.117.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E2443DA2
	for <freebsd-security@freebsd.org>;
	Thu,  9 Nov 2006 15:14:33 +0000 (GMT)
	(envelope-from freebsd-security-local@be-well.ilk.org)
Received: (qmail 5113 invoked from network); 9 Nov 2006 15:14:33 -0000
Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org)
	([66.92.78.145])
	(envelope-sender <freebsd-security-local@be-well.ilk.org>)
	by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP
	for <freebsd-security@freebsd.org>; 9 Nov 2006 15:14:33 -0000
Received: by be-well.ilk.org (Postfix, from userid 1147)
	id 6A74128485; Thu,  9 Nov 2006 09:47:38 -0500 (EST)
To: "mal content" <artifact.one@googlemail.com>
References: <8e96a0b90611080439n558022edj79febf458494ef6e@mail.gmail.com>
	<8e96a0b90611080441t2b486637ya10acd5a1dd77690@mail.gmail.com>
	<44irhq6ngd.fsf@be-well.ilk.org>
	<20061108142306.GA64711@owl.midgard.homeip.net>
	<8e96a0b90611082359jbc85b37kad6109a0aa87598@mail.gmail.com>
From: Lowell Gilbert <freebsd-security-local@be-well.ilk.org>
Date: Thu, 09 Nov 2006 09:47:37 -0500
In-Reply-To: <8e96a0b90611082359jbc85b37kad6109a0aa87598@mail.gmail.com> (mal
	content's message of "Thu, 9 Nov 2006 07:59:22 +0000")
Message-ID: <44slgs3cdy.fsf@be-well.ilk.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: freebsd-security@freebsd.org
Subject: Re: Sandboxing
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: freebsd-security@freebsd.org
List-Id: "Security issues \[members-only posting\]"
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>, 
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2006 15:14:55 -0000

"mal content" <artifact.one@googlemail.com> writes:

> So, uh, is that it?
>
> Nobody sandboxes on FreeBSD?

Right.  The Handbook and FAQ discussions of sandboxes are strictly
there as practical jokes.

Seriously, though, while Erik Trulsson was correct in pointing out the
difference between an X client and an X server (only the latter has
direct access to memory), X clients do have fairly privileged access
to the server, and I don't have a lot of confidence in the safety of a
sandboxed application running in a normal X session.  It's certainly
possible, though; jail(8) and chroot(8) are the obvious places to
start.  As I think I mentioned earlier, I use qemu VMs to do something
similar, although in my case the main point is to start the
application from an *identical* configuration every time.

The trouble with running a complex application (like a web browser) in
a chroot or jail is that it has a long chain of other files it needs
to access at runtime.  Putting all of those inside its captive
directory tree will be quite a bit of work.

Server daemons are a different story; many of them are designed to
work well in a limited environment, and doing so is quite easy.  In
fact, named(8) seems to do that by default on FreeBSD these days.

Be well.