Date: Wed, 20 Oct 2010 15:40:49 -0700 From: Devin Teske <dteske@vicor.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-rc@freebsd.org, Julian Elischer <julian@freebsd.org> Subject: Re: sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5) Message-ID: <1287614449.19873.186.camel@localhost.localdomain> In-Reply-To: <20101020194720.GB1755@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > Then when you copy a > > > file to $ROOTDIR/tmp/ you must be sure there is no symbolic link under > > > the same name, as cp(1) will follow symblic link and you can end up > > > overwriting eg. /etc/spwd.db with /bin/ls. I think it will be easier to > > > just create random directory in $ROOTDIR/tmp/. This all must be done of > > > course when jail is turned off. > > > > I don't follow why the jail has be off. > > Because jailed root can mess with those files during your work (which is > bad in chroot(8) case). I disagree that this is any problem at all. 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. Now, if you're instead talking about the temporary files that are used by the script... We (Garrett and I) discussed earlier in this thread the atomicity of the edit-operation. 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. 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. 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? > > And yes, similarly, the root-user of a jail can poison the shared > > libraries too, but again in the context of chroot/jexec the master host > > is protected. > > > > > > > Also for this reason I'd forget about chroot(8) - > > > even if you remember about libraries, there might still be malicious > > > configuration files, etc. so jexec(8) is the only option. > > > > I fail to see the difference between chroot(8) and jexec(8). Both rely > > on chroot(2). 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. > > So why do you think we have jail and not only chroot? There was never any debate here. Rather, there was a misunderstanding on my part that I thought jexec(8) used chroot(2). Now it makes more sense what you were saying earlier... "Even chroot(2) to jail's root is [unsafe]" > File system > namespace is not everything. when you chroot, a malicious command has > still access to all the other namespaces Right. I just didn't know that jexec(8) relied on a more-secure set of routines (i.e., jail_attach) than chroot(2). > - non-jailed processes being > one. It can then use ptrace to attach to non-jailed process and run with > its privileges and restrictions, ie. outside chroot. Being able to even > signal non-jailed processes alone is not good either. There are plenty > of ways to escape from a chroot when you are root. chroot might be quite > ok when you are running as regular user, but you still have access to > various namespaces even if read-only. There also might be uid collision > - non-jailed uid=1000 user might not be the same as jailed uid=1000 > user, but when running in chroot with this uid you can use non-jailed > uid=1000 process to escape. chroot wasn't really designed for what it is > used and for what you are trying to use it. > > > > Maybe it > > > will be wiser to just limit your script to operate within > > > fully-populated jails, so that you can always call 'jexec <jid> sysrc'? > > > > While that remains an option (and indeed a very valid approach since a > > "service jail" -- that is, a light-weight jail for running single > > daemons etc. in -- is unlikely to have a complementary set of rc.conf(5) > > files). > > > > Though I believe it to still be worth the effort to find a safe-way of > > reaching into the jail to perform the action because it's nice for > > developers to be able to depend on the script to get the job done > > regardless of whether (a) the jail has the script, (b) the jail has an > > untainted copy of the script (though admittedly the latter depends on > > untainted dependencies such as sh(1), grep(1), cp(1), etc.). > > > > But alas, if a safe-way can't be found, then assuredly the `-R dir' and > > `-j jail' options should be removed and the recommendation would be that > > they just copy the script into the jail. > > The -R option is still useful in the same way DESTDIR is useful for > installworld/installkernel and -D option for mergemaster(8). After much discussion, I think: `-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)). By offering both `-R dir' (which relies on chroot(8)) and `-j jail' (which relies on jexec(8)), the hope is that: `-R dir' will be used for: + FreeBSD release engineering (discussed below) + Managing jails on legacy systems lacking jexec(8) Meanwhile... `-j jail' will be used for: + Managing jails on modern systems with jexec(8) ASIDE: FreeBSD release engineering... there's a few rc.conf(5) files in `/usr/release/R' when working your way through FreeBSD release engineering. Having sysrc(8) with `-R dir' option available could mean that a developer wishing to fork his/her own release could write makefiles capable of changing the defaults prior to completing the later stages of release(7) and packing up their own custom OS. -- Cheers, Devin Teske -> CONTACT INFORMATION <- Business Solutions Consultant II FIS - fisglobal.com 510-735-5650 Mobile 510-621-2038 Office 510-621-2020 Office Fax 909-477-4578 Home/Fax devin.teske@fisglobal.com -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <-
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1287614449.19873.186.camel>