From owner-freebsd-security@FreeBSD.ORG Thu Nov 9 15:32:42 2006 Return-Path: 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 3E21A16A4F5 for ; Thu, 9 Nov 2006 15:32:42 +0000 (UTC) (envelope-from artifact.one@googlemail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id C959743D68 for ; Thu, 9 Nov 2006 15:32:20 +0000 (GMT) (envelope-from artifact.one@googlemail.com) Received: by wr-out-0506.google.com with SMTP id i31so113546wra for ; Thu, 09 Nov 2006 07:32:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IdmwO1PE10BEfCmNl6+XTu2VyKbjQnqVyHkriVl6jhkuHl4fZDxAfxWl18XPYTZoYepegUpIoY4Fdoq5n9ZsGZQIDVQrzBxoHj5sHwzxGU+8qZ5hKadaY0hZpaoBpAeefRewd4/8MnZ9SHNV4q2BESMFvWvM2mC0kT2KCU++PRY= Received: by 10.65.219.3 with SMTP id w3mr1452747qbq.1163086339861; Thu, 09 Nov 2006 07:32:19 -0800 (PST) Received: by 10.65.237.20 with HTTP; Thu, 9 Nov 2006 07:32:19 -0800 (PST) Message-ID: <8e96a0b90611090732j78a34d96t16119eba0cdaabc4@mail.gmail.com> Date: Thu, 9 Nov 2006 15:32:19 +0000 From: "mal content" To: freebsd-security-local@be-well.ilk.org In-Reply-To: <44slgs3cdy.fsf@be-well.ilk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <44slgs3cdy.fsf@be-well.ilk.org> Cc: freebsd-security@freebsd.org Subject: Re: Sandboxing X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 15:32:42 -0000 On 09/11/06, Lowell Gilbert wrote: > "mal content" writes: > > > So, uh, is that it? > > > > Nobody sandboxes on FreeBSD? > > Right. The Handbook and FAQ discussions of sandboxes are strictly > there as practical jokes. Damn. They caught me out. > > 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. > I think to really sandbox this program, there are going to have to be changes to the source. I don't really like the idea of creating a filesystem tree for all of Firefox's dependencies. It's that .mozilla directory that causes the headaches. My ideal situation would be: 1. Execute firefox binary under strict resource limits (coredumpsize = 0, memoryuse/datasize = 96000). Ideally some sort of openfiles limit would be nice. Firefox is currently using an amazing number of filedescriptors for what it does: $ fstat | grep firefox | wc -l 190 Now this is the tricky bit: 2. Chroot to /tmp. 3. Drop privileges and connect to X server. I don't think it will be possible to connect to the X server when chrooted in /tmp, due to the reliance on various ~/.x* files. Obviously, it's not possible to chroot without root privileges, so it seems to be mutually exclusive. > > 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. > Yeah, I'm quite painfully aware of the complexity of browsers. Nasty pieces of work (although it's arguably not their fault). > > 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. > And yourself! MC