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

[Pawel Jakub Dawidek]

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

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

So why do you think we have jail and not only chroot? File system
namespace is not everything. when you chroot, a malicious command has
still access to all the other namespaces - 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).

-- 
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/20101020/bf1bc88f/attachment.pgp