DNS lookups inside a chroot (was: security projects thoughts)

[Jordan K. Hubbard]

Might work, but I'm just guessing.  Someone would have to try it and then see if there were any similar problems of this nature still lurking - getting Xcode to run in a chroot, for example, is a lot harder than just getting enough infrastructure together to run configure scripts and makefiles.  Even my earliest experiments with this never succeeded in getting all of the xcodebuild scenarios to work, and I was never totally sure why (had all the right filesystems mounted in or on /dev, etc).  Kevin has convinced me that this is a dead-end and something entirely non-chrooty needs to be invented. :-)

- Jordan

On Apr 17, 2011, at 6:45 PM, Jeremy Huddleston wrote:

> Could you run a process outside of your chroot that will create a socket at /path/to/chroot/var/run/mDNSResponder as a proxy for /var/run/mDNSResponder?  I'm sure there are a ton of other similar issues lurking around, but that should at least work for communicating with mDNSResponder.
> 
> On Apr 17, 2011, at 14:25, Jordan K. Hubbard wrote:
> 
>> 
>> On Apr 17, 2011, at 1:33 AM, Joshua Root wrote:
>> 
>>> Maybe you can help me out then. :-) I can't get (lib)curl or ping to
>>> work inside a chroot (as created by MPAB) because their DNS lookups fail:
>> 
>> I asked around and this is apparently a known issue with the chroot environment being unable to contact the mDNSResponder socket.  Untested, but what might work is running your own copy of mDNSResponder inside the chroot - copy the appropriate command line args out of the launchd plist for it.  This is one of those areas where chroot(1) is simply becoming more and more incompatible with Mac OS X (despite my earlier assertions that you should "just chroot") due to all the services that need to run.  A chroot environment does not have a launchd managing it, for example, yet something like that is what's really needed if you're going to run a shell in a chroot environment as if it were a fully-fledged instance of the system.
>> 
>> Perhaps a better idea would be to enhance trace mode such that it "faults in" stuff on demand into a run-specific staging area.  Read-only opens of the files in the system would succeed, of course, it being only creations or rw/append opens which forced the copy, which means it wouldn't run all that slowly either.  What's the current behavior of trace mode across fork/exec boundaries?  Do the children get the properly interposed library such that they're also talking to the trace bits rather than the filesystem APIs directly?
>> 
>> - Jordan
>> 
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> 
>