From owner-freebsd-rc@FreeBSD.ORG Thu Oct 21 11:07:03 2010 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D597F106564A; Thu, 21 Oct 2010 11:07:03 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 46AFE8FC08; Thu, 21 Oct 2010 11:07:03 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1ACA745CAC; Thu, 21 Oct 2010 13:07:02 +0200 (CEST) Received: from localhost (pdawidek.whl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 4B5D645C8A; Thu, 21 Oct 2010 13:06:56 +0200 (CEST) Date: Thu, 21 Oct 2010 13:06:25 +0200 From: Pawel Jakub Dawidek To: Devin Teske Message-ID: <20101021110625.GA2624@garage.freebsd.pl> References: <1286925182.32724.18.camel@localhost.localdomain> <1286996709.32724.60.camel@localhost.localdomain> <1287448781.5713.3.camel@localhost.localdomain> <1287510629.25599.2.camel@localhost.localdomain> <20101019195225.GB2127@garage.freebsd.pl> <1287540769.25599.73.camel@localhost.localdomain> <20101020100042.GE2127@garage.freebsd.pl> <1287594703.19873.58.camel@localhost.localdomain> <20101020194720.GB1755@garage.freebsd.pl> <1287614449.19873.186.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <1287614449.19873.186.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=4.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-rc@freebsd.org, Julian Elischer Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 11:07:03 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 20, 2010 at 03:40:49PM -0700, Devin Teske wrote: > On Wed, 2010-10-20 at 21:47 +0200, Pawel Jakub Dawidek wrote: > > On Wed, Oct 20, 2010 at 10:11:43AM -0700, Devin Teske wrote: > > > I don't follow why the jail has be off. > >=20 > > Because jailed root can mess with those files during your work (which is > > bad in chroot(8) case). >=20 > I disagree that this is any problem at all. >=20 > Previously in the thread we discussed how copying the script into the > jail and then executing said script is bad. This is no longer a problem > because the script is now piped into a jailed sh(1) process. Even if the > assumed-malicious root-user of the jail was able to (a) interrupt the sh > (1) process executing within his jail and (b) somehow take control of > the standard input file-descriptor feeding the script to the process, he > still wouldn't be any closer to causing a problem in the master-host. If > "rm -Rf /*" was injected into the input stream, it would only destroy > the jail, not the master-host. If you read entire sentence you will note, that I was talking about chroot(8) case, not about jexec(8) case:) > Now, if you're instead talking about the temporary files that are used > by the script... >=20 > We (Garrett and I) discussed earlier in this thread the atomicity of the > edit-operation. >=20 > We use mktemp(1) to allocate a temporary file in a manner that is safe > from race-conditions. > > When we're done operating on the temporary file, we perform a mv(1) to > overwrite the destination file with the temporary file. >=20 > Yes, it's true that the malicious root-user can hypothetically munge the > temporary file before eventually overwriting the destination file, but > again... he'd only be destroying his own jail. Exactly, it is good that you are aware that mktemp(1) doesn't protect in any away against jailed root. > Race-conditions and malicious users aside (which should be of no concern > given the above setup), what else could possibly require a jail to be > powered down during the operation? Let this be clear. I was discussing chroot(8) case. > > > I fail to see the difference between chroot(8) and jexec(8). Both rely > > > on chroot(2). >=20 > Correction, I was wrong. I took a peek at usr.sbin/jexec/jexec.c and > found that it uses the new jail_attach() function from libc. You were partially right - jail does use chroot functionality, but internally, in the kernel, but chroot is only one of the restrictions. > After much discussion, I think: >=20 > `-R dir' will use chroot(8) and the man-page should warn users that this > should _not_ be used to manage jails (that if they want to manage a > jail, they should use instead `-j jail' which relies on jexec(8)). Sounds reasonable. Apart from documenting it, checking if the given directory for -R option is a root of one of the running jails and warning about it would be nice too. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzAHrEACgkQForvXbEpPzTcswCg+GC7l9twFYIJSNAIjTonEI8b nLAAn1UFOxoQedRZE1Qhq+L7h2sMHfsd =eBJW -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--