That’s a cool idea. It might break an exploit chain, disable some exploit payloads, make exploitation harder. Non-perfect as per Are non-perfect Defenses that defeat off-the-shelf Viruses a worthwhile Development Goal? or could it be in some cases really strong?
Similar to:
- Automatically creating a mandatory access control profile based on parsing the binary (or source code).
- Automatically creating an apparmor profile based on parsing the binary (or source code).
I am wondering why nobody earlier got that idea? Or did someone?
A bit similar to this:
Design:
- For sure keep this in a separate file for better abstraction. Might even be useful for some other purpose. A good addition to https://gitlab.com/whonix/helper-scripts? (Not important if you prefer to keep all inside sandbox-app-launcher package.)
- helper-scripts package shouldn’t change anything on the system. Should have most minimal risk of breaking unrelated packages that don’t depend on it. Should just be a vehicle to ship files. Therefore the parser could be added there.
- The caching of parsed information, folder creation however belong into sandbox-app-launcher package since that is making more intrusive file system modifications.
- Have a feature in sandbox-app-launcher to disable/enable this feature per application using the usual config snippets. (Default: enabled, if attainable/realistic development milestone.)
With sandbox-app-launcher we have to worry about too things:
- local privilege escalation vulnerabilities
- sandbox escape vulnerabilities
And sandbox-app-launcher might be used to start two different types of binaries:
- those which “only” contain vulnerabilities and/or bugdoors
- those containing specifically crafted code intended to exploit the parser and its dependencies (currently
objdump,ldconfig,pacman(not on Debian), sandbox-app-launcher (not sure the attack surface of itself), its dependenciessudo,bash,bubblewrap
Therefore it might make sense to run the parser (and its dependencies) itself through either sandbox-app-launcher, bubblewrap and/or some mandatory access control?
At the end of the script, check that variable all_paths contains only white listed characters? (To avoid crafted, malicious contents of being re-used in command line options later by sandbox-app-launcher calling sudo, bwrap.)
printf, /usr/bin/printf by coreutils: What’s the security record of that? Any way that printf can lead to unwanted code execution? Really required to use printf instead of bash’s built-in echo?