From owner-freebsd-security@FreeBSD.ORG Tue Mar 31 19:37:24 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11F83E81 for ; Tue, 31 Mar 2015 19:37:24 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id DF152A65 for ; Tue, 31 Mar 2015 19:37:23 +0000 (UTC) Received: by be-well.ilk.org (Postfix, from userid 1147) id CE41233C22; Tue, 31 Mar 2015 15:37:22 -0400 (EDT) From: Lowell Gilbert To: Slawa Olhovchenkov Subject: Re: ftpd don't record login in utmpx References: <20150330142543.GD74532@zxy.spb.ru> <44y4me9gfi.fsf@lowell-desk.lan> <20150331034402.GE74532@zxy.spb.ru> Date: Tue, 31 Mar 2015 15:37:22 -0400 In-Reply-To: <20150331034402.GE74532@zxy.spb.ru> (Slawa Olhovchenkov's message of "Tue, 31 Mar 2015 06:44:02 +0300") Message-ID: <44oan9t0ul.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:37:24 -0000 Slawa Olhovchenkov writes: > On Mon, Mar 30, 2015 at 08:08:49PM -0400, Lowell Gilbert wrote: > >> Slawa Olhovchenkov writes: >> >> > ftpd from FreeBSD-10 and up don't record ftp logins to utmpx database >> > (for case of chrooted login). >> > This is lack security information. >> > I found this is done by r202209 and r202604. >> > I can't understand reason of this. >> > Can somebody explain? >> >> Having a jail log into the base system is a security issue in the >> making. Can't you do this in a safer way by doing remote logging to the >> base system rather than having the jail hold on to a file handle that >> belongs outside the jail? > > Jail? Why I you talk about jail? Because the principle is the same for any method of imprisoning a process inside a particular file tree, whether it be chroot(8) or jail(8) or a virtualized machine. The principle is: don't give the imprisoned process access to any resources outside of its prison. >> It's certainly possible to maintain these kinds of capabilities, but >> you would have to convince code reviewers that the same results can't be >> achieved some other way that's easier to secure. > > Can you explain some more? > A im lost point. You can always try to limit the ways that direct access outside the chroot (et. al.) can be used (or abused). However, it is much easier to make sure that there are no ways to break out of the chroot if the direct access does not exist in the first place.