From owner-freebsd-security Wed May 17 15:49:16 2000 Delivered-To: freebsd-security@freebsd.org Received: from falcon.grobin.org (falcon.grobin.org [204.225.173.44]) by hub.freebsd.org (Postfix) with ESMTP id 05ECD37B610; Wed, 17 May 2000 15:49:03 -0700 (PDT) (envelope-from geoff@grobin.org) Received: by falcon.grobin.org (Postfix, from userid 1000) id F326D2D5; Wed, 17 May 2000 18:51:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by falcon.grobin.org (Postfix) with ESMTP id ECBC4ED; Wed, 17 May 2000 18:51:04 -0400 (EDT) Date: Wed, 17 May 2000 18:51:04 -0400 (EDT) From: Geoffrey Robinson To: Robert Watson Cc: security@freebsd.org Subject: Re: Jail: Problems? Proper Usage? Status? Practicality? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 May 2000, Robert Watson wrote: > > If a process running in the host system created a UNIX domain socket or > > named pipe within the jail directory tree. Would a process running in the > > jail be able to connect to and communicate with the host process through > > this socket or pipe? If so I guess you could create work around for just > > about anything by running it on the host system. Would this create a > > potential way of defeating the jail? > > Jail works by: > > 1) Chrooting the child process > 2) Limiting the scope of superuser privileges accessible by uid0 processes > in the jail > > It does not attempt to prevent processes outside the jail from > communicating with processes within the jail. As such, having a process > do so wouldn't defeat the jail per se, but would defeat the purpose of the > jail :-). Still, like any network service the security impact would depend on how well the server application was written not on the fact you have a link to the host system. Right? > I'm not clear on why that would happen -- the libc (etc, etc) in each jail > should be kept in synch with the kernel, however, and that could be source > of your problems. I.e., if you upgrade the kernel, it exports the same > syscall interface to all processes, regardless of jails, so all jails > making use of syscalls that have changed need to be upgraded in synch. > > This is the same as upgrading the kernel without upgrading your normal > world. > > One way to substantially improve jail scalability would be to allow the > same (read-only) file system to be present in all jails as the root, with > only jail-local data being modified. You can imagine gratuitously using > nullfs (if it worked) to do this, and mount per-jail writable fs's for > appropriatel subdirectories (/etc, /usr/local, /home) with appropriate > symlinks within the jail. Right now, each jail costs you the size of > world, and is hard to upgrade if you have any decent number of jails. > Storing all that stuff in a single tree mapped read-only into jails would > solve that (you'd probably want two so you could upgrade one, test it, and > then swap to that for all jails so as to minimize downtime). If I wanted to do that. Would it be as easy as building a jail on a spare partition then mounting it read-only to the correct locations? ------------------------------------------------------------------------------ | Geoffrey Robinson - geoff@grobin.org | ------------------------------------------------------------------------------ Random Fortune Quote "What's another word for Thesaurus?" -- Steven Wright To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message