Beware this can be used for security-purposes, but it can deliberately be circumvented. Soapbox only impacts dynamically linked programs that properly use glibc functions. I'm currently looking into a safer implementation using ptrace.
Soapbox also triggered some bugs in applications that trusted system calls too much. So you can use soapbox to test your programs for these kinds of mistakes too.
According to the Jargon File, a sandbox is "A controlled environment within which potentially dangerous programs are run.".
It was written to sandbox my RPM build system to prevent pollution of my clean build environments by untrusted Makefiles. Intelligent people would wonder why building package as a user isn't sufficient.My aim was to try to complete the build-process as successful as possible, and present the builder with all the errors that occured. The most important fact being to automate as much as possible (creating automated mails for upstream developers, building large sets of packages automatically). Reducing the time to fix broken scripts and reducing the number of broken builds before a clean package is created. Time is precious.
Soapbox is optimized with that purpose in mind.
- Define one or more directories where write-access is allowed (SOAPBOXPATH)
- Define a logfile (so that output won't disturb programs) (SOAPBOXLOG)
- 3 types of action to be taken on illegal (write) access (SOAPBOXACTION)
- warn: report and fake successful completion of illegal systemcalls (default)
- err: report and return access denied
- halt: exit the process successfully immediately
- Extensive runtime debugging options (SOAPBOXDEBUG)
- program execution
- library calls
- overloaded systemcalls
- internal functions (rewriting files)
- A Soapbox wrapper script is available for your pleasure
Read more...
http://dag.wieers.com/home-made/soapbox/
Don
No comments:
Post a Comment