sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5)

[Pawel Jakub Dawidek]

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

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

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

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20101021/4c7f9024/attachment.pgp