From owner-freebsd-arch Sat Apr 28 17:30:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 013C337B422 for ; Sat, 28 Apr 2001 17:30:44 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f3T0VDf06567; Sat, 28 Apr 2001 20:31:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 28 Apr 2001 20:31:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: scanner@jurai.net Cc: freebsd-arch@FreeBSD.ORG Subject: Re: jailNG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 28 Apr 2001 scanner@jurai.net wrote: > On Sat, 28 Apr 2001, Robert Watson wrote: > > > The jail() code doesn't allow user applications to open raw sockets > > permitting direct use of ICMP by user processes, but all of the normal use > > of ICMP by the network stack directly is uninhibited. This means that > > things like PMTU discovery work just fine, but applications such as ping > > do not work in jail(). It's possible to imagine modifications to the raw > > socket behavior that might permit use of it from within jail(), but > > there's a whole can of worms there that we're not willing to spend too > > much time on at this point. > > Ok. I wasn't sure. I couldnt believe it would block ICMP. I knew there > was a logical system with its behaviour. I actually like the current way > then. I see jail as a virtual hosting env. more then anything else. > Thanks for the explanation. Yeah -- there are three basic function of jail(): 1) Cause the suser() call to work only in a specifically designated set of cases (using the PRISON_ROOT flags to suser_xxx() permits the call to succeed in jail()). 2) Institute a set of simply mandatory inter-process restrictions preventing a set of inter-process operations from taking place (such as debugging, signalling, et al from within the jail to outside the jail()). 3) Rewrite or block certain socket operations so that listen and connect operations in the IP space use the IP designated for the jail(), and so that access to some other protocols (such as IPv6) can be disabled. This in effect provides a simple form of poly-instantiation for the localhost address (by substituting the jail IP for 127.0.0.1), but also has some other side effects that I'm looking at ways to remedy in the future (hopefuly without virtualizing the entire stack, which would work, but has a lot of negative sides.) The access to ICMP is a property of (1), not of (3). Jail's impact on the IP stack happens almost exclusively as part of the socket implementation, and doesn't get down into the network layer much. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message