0

I was wondering if it's possible to write a shell script that:

  • runs chroot for a given userspec and group

  • monitors/intercepts system calls all processes started, and what libraries they attempt to load, and if the file is not available in the chroot path, but is available in the "normal" system path, instead of failing the access, lets them access the missing file in it's original location outside of the chroot jail, and logs this fact to a log file.

  • for example, process tries to start /bin/ls, but it's not in the chroot path. a system call hook figures this out, and notices that /bin/ls does exist in the main system /bin path, so this file is cached into the user's chroot and logged.

  • once the user exits, and the missing files are noted, a script is created that allows the missing files to to be included for the next time the chroot command is used by this user.

the idea is you'd use this to "test" a setup and craft the actual chroot jail that's deployed for normal use, rather than by trial and error.

it has the advantage of (assuming you start with an "empty" jail, knowing precisely what files are known to be needed, and have been provisioned for future use.

i suppose there is no reason why the "live" system couldn't proxy file calls in this way too, however it would need to be well monitored. i suspect it would be very slow due to all the monitoring, so you would not want to run like this long term, but you could have some threshold where a process not needing to proxy files for x number of restarts, would migrate to the non monitored version which would offer the performance increase.

does anything like this exist? if not, what tools would one use to craft such a concept?

1 Answers1

0

necessity being the mother of invention... i'm answering my own question after muddling about and making something similar to what i described

here is my mother of an invention

https://github.com/jonathan-annett/chroot-node-app

whilst ldd does a fairly good job of identifying what libraries are needed for a given executable, it doesn't take into account libraries that are loaded based on decisions made by the executable itself at runtime. ping, for example seems to need a few extra libs that are not detected by ldd.

so i designed a system that lets you run a given app using strace on the commandline and saving the output to a log file in the chroot envrionment. externally another script parses that log and finds the missing files and puts them in the correct location, and adds the extra files to the original build list.