Date: Wed, 20 Oct 2010 12:00:42 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Devin Teske <dteske@vicor.com> 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: <20101020100042.GE2127@garage.freebsd.pl> In-Reply-To: <1287540769.25599.73.camel@localhost.localdomain> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--O8XZ+2Hy8Kj8wLPZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2010 at 07:12:49PM -0700, Devin Teske wrote: > On Tue, 2010-10-19 at 21:52 +0200, Pawel Jakub Dawidek wrote: > > On Tue, Oct 19, 2010 at 10:50:29AM -0700, Devin Teske wrote: > > > I added `-j jail' for specifying a jail id or name to operate within > > > (requires jls(8); overrides `-R dir'). > > [...] > >=20 > > Note that operating on jail files from outside a jail is serious > > security problem. The files from within the jail can be symbolic links > > that point to files from outside a jail from your perspective. Even > > chroot(2) to jail's root is neither safe (running applications that can > > be modified by jail's root is obvious security hole) nor reliable (jail > > might not have all the commands). The only safe way is to jexec(8) into > > a jail, but it of course has the same relialability issue as chroot(8). > >=20 >=20 > I see the concern, and you're absolutely right. >=20 > I did see the need to use either chroot(8) or jexec(8), but for exactly > the same reasons you mention (handing execution off-to something that > could have been modified by the jail's root-user), I ended up writing > routines that just edited the files outside the jail. >=20 > It appears that (due to the other aforementioned security problem, > involving hand-crafted symbolic links with malicious-intent), the only > proper solution would be: >=20 > a. Copy ourselves into some temporary location within the jail > b. Hand execution off to ourself using either jexec(8) or chroot(8) >=20 > And in doing that, we'll be properly jailed so that no matter the attack > vector, we'll be covered via the kernel's built-in protection. >=20 > How does that sound? Well, first of all you need to verify that $ROOTDIR/tmp/ is not a symbolic link (you can use realpath(1) for that). 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. Anoher issue to consider is that you have to copy statically linked utilities - dynamically linked programs will use libraries from within a jail, which might not be there and might not be trusted. 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, for one, use read-only root file systems for jails, maybe it would be good to check for that if you want to copy stuff over (/tmp/ is still writable). Please note, that all this is very risky still. I don't know if warned you about all possible problems. I'm also not a fun of copying stuff over into jails - this isn't pretty and also it is a problem to clean up (think about system crash in the middle of your operation). 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'? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --O8XZ+2Hy8Kj8wLPZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEUEARECAAYFAky+vcoACgkQForvXbEpPzS5IwCY+e1kHMg5jz5S4xi30T7fI8Qx +ACdEaFG38wMFUjA7jnlyzSOOVMYTec= =LwKF -----END PGP SIGNATURE----- --O8XZ+2Hy8Kj8wLPZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101020100042.GE2127>