From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 28 16:22:07 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC80616A4DD for ; Mon, 28 Aug 2006 16:22:07 +0000 (UTC) (envelope-from dking@ketralnis.com) Received: from ketralnis.com (melchoir.ketralnis.com [68.183.67.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B79F43D72 for ; Mon, 28 Aug 2006 16:22:07 +0000 (GMT) (envelope-from dking@ketralnis.com) Received: from [192.168.1.27] (pix.xythos.com [64.154.218.194]) (authenticated bits=0) by ketralnis.com (8.13.6/8.13.6) with ESMTP id k7SGM683086929 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 28 Aug 2006 09:22:06 -0700 (PDT) (envelope-from dking@ketralnis.com) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20060828150039.21e8bd4a@localhost> References: <44F0E38F.5030809@erdgeist.org> <17648.59470.572563.377998@bhuda.mired.org> <20060827052733.F16322@erdgeist.org> <17649.9146.307818.780974@bhuda.mired.org> <44F1B7B7.9090701@erdgeist.org> <17649.54252.987757.501860@bhuda.mired.org> <20060828150039.21e8bd4a@localhost> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F8CA526-B1E8-4427-90A6-8FA8B56D0CF3@ketralnis.com> Content-Transfer-Encoding: 7bit From: David King Date: Mon, 28 Aug 2006 09:21:52 -0700 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.752.2) Subject: Re: jails, cron and sendmail X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 16:22:07 -0000 >>>> The default configuration doesn't expose sendmail to the publicly >>>> visible IP addres. The daemon it runs only listens for >>>> connections to >>>> the localhost address. >>> Which is rewritten to the jails (externally visible) address on a >>> connect() >> Yup. I wasn't aware of that strange behavior of jails. That should be >> fixed. > Fixed how? Disallow jailed applications to connect to 127.0.0.1, > and thus break most of them, or have them reach 127.0.0.1 on the > host system and weaken the security? Would it be too much to ask to let the system keep lo0, and give the first jail lo1, the second jail lo2...? That is, a separate loopback for each jail?