How to isolate file access for program?

cbh2000 · 03-12-2011, 04:16 PM

I am wondering if it is possible to change the root directory for a single, particular program. For example, I have an executable, 'miscreant.bin' that has all of it's required libraries in a directory named "libraries", in the same directory as the said executable.

I can launch the program and make it use the libraries included with the executable rather than the system with:

Code:

/lib/ld-linux.so.2 --library-path ~/miscreant/libraries ~/miscreant/miscreant.bin

...or...

Code:

env LD_LIBRARY_PATH=~/miscreant/libraries ~/miscreant/miscreant.bin

With either, miscreant can be portable. But, I would also like to change the root directory (like chroot) of miscreant, so that the directory "~/miscreant/sandbox" becomes the root ("/"). So, if miscreant created a file named "/home/bryan/miscreant", it will be redirected to "~/miscreant/sandbox/home/bryan/miscreant".

I am running Crunchbang 10 (Statler) on a 32-bit Atom netbook.

corp769 · 03-12-2011, 05:12 PM

What you could do is create a script and have it contain a variable to have the absolute path of your choice. Then you can pre-pend the variable to the command and voila. Just my two cents.

Cheers,

Josh

Noway2 · 03-12-2011, 06:24 PM

Just a thought, but have you looked at using chroot? If so, I am curious as to why it isn't a solution for you. I ask because I am not really up on all the ins-and-outs of how to use it, but it sounds like it does all or at least most of what you want and it looks like you have met the major requirements by having the libraries and binaries self contained. The (free) book Linux From Scratch has a good section on setting up a chroot environment, including the preparatory bindings and creation of a the /proc file system based off of the primary one if you would like to look at a easy to follow example.

cbh2000 · 03-12-2011, 09:02 PM

Quote:

Originally Posted by corp769

What you could do is create a script and have it contain a variable to have the absolute path of your choice. Then you can pre-pend the variable to the command and voila. Just my two cents.

Cheers,

Josh

I don't understand. Are you talking about an environment variable? And how do you prepend the variable to the command?

Quote:

Originally Posted by Noway2

Just a thought, but have you looked at using chroot? If so, I am curious as to why it isn't a solution for you. I ask because I am not really up on all the ins-and-outs of how to use it, but it sounds like it does all or at least most of what you want and it looks like you have met the major requirements by having the libraries and binaries self contained. The (free) book Linux From Scratch has a good section on setting up a chroot environment, including the preparatory bindings and creation of a the /proc file system based off of the primary one if you would like to look at a easy to follow example.

That was my first attempt, and after what you have just said I probably should look into it deeper. The problems I have with chroot are these:
- chroot requires root access. (Okay, not a big deal... )

- chroot requires the program and all of it's dependencies to be inside the chroot'ed directory. I only want to redirect all file operations to a directory, not run it in it's own environment. If I have to modify libc or whatever library handles file operations, I will, but I am looking for a solution that already exists.
- chroot must run the program, as opposed to simply running the program. (For what I am going to use this for, this is a major inconvenience).
- I cannot get it to work.

Running "sudo chroot /media/sda6/bryan/dev/cplib-build-desktop/portable /cplib" gives me this error:

Code:

"chroot: cannot run command `/cplib': No such file or directory"

ls "/media/sda6/bryan/dev/cplib-build-desktop/portable" returns:

Code:

cplib          libdl.so.2        libgthread-2.0.so.0  libpthread.so.0  libstdc++.so.6
ld-linux.so.2  libgcc_s.so.1     libm.so.6            libQtCore.so.4   libz.so.1
libc.so.6      libglib-2.0.so.0  libpcre.so.3         librt.so.1       run-cplib-portably.sh

cplib is configured to search in the directory it is in for libraries (using 'patchelf --set-rpath ./ cplib').

I suspect it is because required system functionality is not duplicated in the new environment. Maybe it requires a shell? Anyway, I don't want to duplicate it (I imagine that this would be inefficient for many programs).

Thanks for the insightful replies!

cbh2000 · 03-12-2011, 10:04 PM

Okay, so I got chroot to work:

Code:

root@bryanpc:/home/bryan/echo# cp ./*.so* ./root/lib
root@bryanpc:/home/bryan/echo# cp ./echo ./root/bin
root@bryanpc:/home/bryan/echo# chroot ./root /bin/echo

Now I will see if I can iron out the other issues...

I got a hold of chroot's source code. As it turns out, it is basically a wrapper around the function 'int chroot(const char*)' in 'unistd.h'. Now, if I could find the package containing the source code for 'unistd'.

cbh2000 · 03-13-2011, 03:23 PM

http://linuxgazette.net/161/laycock.html:

Quote:

Inside the kernel is the function "sys_chroot". It checks for the CAP_SYS_CHROOT capability. Then, it simply changes the "current->fs" global structure's "rootmnt" and "root" fields to the filename's "dentry". Other code then uses these fields to determine the root directory. Have a look in the kernel sources in fs/open.c and fs/namespace.c (the function name is 'set_fs_root') for more info.

So, now I can delve into the source code and find out how the chroot function works and modify it to suit my needs! Also, I found the code for ld-linux.so.2: it is part of either the eglibc or glibc project (depending on your distro), located in the file "eglibc-2_12/libc/elf/dl-load.h". ld-linux.so.2 handles the searching and loading of shared libraries.

This way, I can run (and upload) portable programs securely without virtualization/emulation.