3

Gentoo has a feature in portage, that prevents and logs writes outside of the build and packaging directories.

Checkinstall is able to monitor writes, and package up all the generated files after completion.

Autotools have the DESTDIR macro that enables you to usually direct most of the filesystem activity to an alternate location.

  • How can I do this myself with the safety of the Gentoo sandboxing method?
  • Can I use SELinux, rlimit, or some other resource limiting API?
  • What APIs are available do this from C, Python?

Update0

  • The mechanism used will not require root privileges or any involved/persistent system modification. This rules out creating users and using chroot().
  • Please link to the documentation for APIs that you mention, for some reason they're exceptionally difficult to find.

Update1

  • This is to prevent accidents. I'm not worried about malicious code, only the poorly written variety.
Matt Joiner
  • 112,946
  • 110
  • 377
  • 526
  • You need to define your threat model. Are you looking to protect against accidents (gentoo portage sandbox) or are you trying to protect against sophisticated attackers actively trying to subvert your security? For the latter, I recommend apparmor, selinux, and grsecurity (in increasing order of security IMHO). Doing virtualization with one type of security in the host and a different type in the guest is even better, though still by no means guaranteed. – Seth Robertson Jun 21 '11 at 00:37

5 Answers5

2

The way Debian handles this sort of problem is to not run the installation code as root in the first place. Package build scripts are run as a normal user, and install scripts are run using fakeroot - this LD_PRELOAD library redirects permission-checking calls to make it look like the installer is actually running as root, so the resulting file ownership and permissions are right (ie, if you run /usr/bin/install from within the fakeroot environment, further stats from within the environment show proper root ownership), but in fact the installer is run as an ordinary user.

Builds are also, in some cases (primarily for development), done in chroots using eg pbuilder - this is likely easier on a binary distribution however, as each build using pbuilder reinstalls all dependencies beyond the base system, acting as a test that all necessary dependencies are specified (this is the primary reason for using a chroot; not for protection against accidental installs)

bdonlan
  • 224,562
  • 31
  • 268
  • 324
0

There are two methods to do this. One is to use LD_PRELOAD to hook library calls that result in syscalls, such as those in libc, and call dlsym/dlopen. This will not allow you to directly hook syscalls.

The second method, which allows hooking syscalls, is to run your executable under ptrace, which provides options to stop and examine syscalls when they occur. This can be set up programmatically to sandbox calls to restricted areas of the filesystem, among other things.

Community
  • 1
  • 1
Matt Joiner
  • 112,946
  • 110
  • 377
  • 526
0

One approach is to virtualize a process, similar to how wine does it, and reinterpret file paths. That's rather heavy duty to implement though.

A more elegant approach is to use the chroot() system call which sets a subtree of the filesystem as a process's root directory. Create a virtual subtree, including /bin, /tmp, /usr, /etc as you want the process to see them, call chroot with the virtual tree, then exec the target executable. I can't recall if it is possible to have symbolic links within the tree reference files outside, but I don't think so. But certainly everything needed could be copied into the sandbox, and then when it is done, check for changes against the originals.

wallyk
  • 56,922
  • 16
  • 83
  • 148
  • You can't have symlinks pointing outside of a chroot - the dereferencing happens inside the chroot context. – nobody Jun 21 '11 at 00:36
  • chroot() doesn't have a good history of security. Linux kernel devs don't consider it a security tool and thus security issues are often ignored (compared to, say, FreeBSD's jail()). It is better than a poke in the eye, of course. – Seth Robertson Jun 21 '11 at 00:39
0

Maybe get the sandbox safety with regular user permissions? So the process running the show has specific access to specific directories.

chroot would be an option but I can't figure out how to track these tries to write outside the root.

Another idea would be along the lines of intercepting system calls. I don't know much about this but strace is a start, try running a program through it and check if you see something you like.

edit:

is using kernel modules an option? because you could replace the write system call with your own so you could prevent whatever you needed and also log it.

Vinicius Kamakura
  • 7,665
  • 1
  • 29
  • 43
0

It sounds a bit like what you are describing is containers. Once you've got the container infrastructure set up, it's pretty cheap to create containers, and they're quite secure.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304