Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Oct 2010 10:11:43 -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:  <1287594703.19873.58.camel@localhost.localdomain>
In-Reply-To: <20101020100042.GE2127@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>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2010-10-20 at 12:00 +0200, Pawel Jakub Dawidek wrote:
> 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').
> > > [...]
> > > 
> > > 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).
> > > 
> > 
> > I see the concern, and you're absolutely right.
> > 
> > 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.
> > 
> > It appears that (due to the other aforementioned security problem,
> > involving hand-crafted symbolic links with malicious-intent), the only
> > proper solution would be:
> > 
> > a. Copy ourselves into some temporary location within the jail
> > b. Hand execution off to ourself using either jexec(8) or chroot(8)
> > 
> > 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.
> > 
> > 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).

Agreed. I think I'm going to abandon that approach. It seems much
cleaner to just pipe input into a jailed sh(1) process.


>  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.


>  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.

Do we really care about "trust" in the chroot(8) or jexec(8) (chroot(2))
context?

Yes, you're right that if my script calls cp(1) within the jail and the
root-user of the jail has poisoned it (perhaps replacing it with a shell
script that does an "rm -Rf /*"), nothing will happen to the master-host
-- only the jail itself will be destroyed (because the sh(1) process
executing my script is jailed into the new root).

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).


> 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).

Abandoning the idea that I have to write some file into the jail's
filesystem heirarchy. Much more efficient to fire up an sh(1) process
via chroot(8) or jexec(8) and then pipe standard input to it.


> 
> 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).

Yep. Abandoning the copy-in method.


>  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.
-- 
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?1287594703.19873.58.camel>