Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Nov 1999 19:44:38 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        David Gilbert <dgilbert@velocet.ca>
Cc:        security@FreeBSD.ORG
Subject:   Re: sandboxed bind.
Message-ID:  <199911140344.TAA32979@apollo.backplane.com>
References:  <bulk.47978.19991113192456@hub.freebsd.org> <14382.11991.536272.989358@trooper.velocet.net>

next in thread | previous in thread | raw e-mail | index | archive | help

:I went through the motions to sandbox bind.  My only real complaint
:was that named-xfer was dynamically loaded (greatly increasing the
:cruft that had to be in the sandbox).
:
:Is there an easy way to determine exactly what libraries are required
:by an executable, BTW?
:
:Dave.
:
:-- 
:============================================================================
:|David Gilbert, Velocet Communications.       | Two things can only be     |

    'ldd programname'

    Another thing you can do which works quite well is to simply ktrace
    named when you start it up:

    ktrace -i -t cn named....

    Let it run for a while, including allowing it to fork/exec whahtever
    programs it needs to fork/exec, and then do a 'ktrace -C' to turn off
    the ktracing.

    You can then do:

	kdump -R | less

    You can grep through the kdump output too to locate the files that
    named opened, including libraries loaded and auxillary files opened
    by clib and other libraries.

    I don't use chrooted environments myself... I used to but they're just
    too difficult to maintain across updates and other things.  It would
    be nice if there were something inbetween -- something that, for example,
    disables suid and sgid within a set of processes that works in a manner
    similar to a chroot'd environment.  Without access to suid/sgid binaries
    there is precious little a program run in a user/group sandbox can do
    outside the sandbox.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911140344.TAA32979>