It’s an interesting idea!
Could you please describe the threat model? I guess it assumes a compromise of a user account (probably most likely user user?) and then malware under that account using LD_PRELOAD tricks to sniff what other applications are doing (such as sniffing keystrokes, passwords, memory?)
I guess complexity is low enough (which is a very good thing - I can ask some people for code review since small enough). Doesn’t need its own Makefile. Could be added to package security-misc and compiled during postinst similar to bindp.postinst?
There are a few legitimate uses of LD_PRELOAD in Whonix and Kicksecure:
- uwt uses
torsocks(for stream isolation) (torsocksas per its man page is a wrapper that adds the torsocks LD_PRELOAD) andbindp(to change local listen interface). - Hardened Malloc
These are all based on LD_PRELOAD. Therefore do you think you could add some kind of root configurable whitelist .d mechanism?
Other things needed:
- license header
- some test
- whitelisted.so ld preload lib saying “i am here and this is good”
- blacklisted-test.so ld preload lib saying “i am here and this is an error”
- then the test script could look if the whitelisted lib is still there and the blacklisted one got filtered out. (We don’t want to break torsocks, stream isolation, bindp, hardeneed malloc.)
Nitpick: maybe shouldn’t be called rootkit-detect. While it would be great to have a fully featured rootkit detection installed by default, and while this is really cool, it doesn’t cover all of that. There are many ways to implement rootkits (such as kernel rootkits) which wouldn’t be covered here.
ld-system-preload-disable requires root if I am not mistaken. Therefore out of threat model because…
Right?
I don’t think so. Not when going the LD_PRELOAD route. The LD_PRELOAD mechanism is “somewhat limited”. System wide preloading is what /etc/ld.so.preload is for. We discussed options for LD_PRELOAD in Hardened Malloc - Hardened Memory Allocator and didn’t find too many options for that.
Related:
Unless there is any different approach of environment variable filtering / enforcement. I might have more ideas (or at least contribute to brainstorming) once you described the threat model.
Environment variables have a parent / child relationship. Environment variables can be set by the parent process and are inherited by the child process. I guess the threat model here is that the parent shall be untrusted. The parent might be compromised and set malicious environment variables. Therefore we need to look closer at the parent. Who is the actual parent process here? Let’s look at pstree.
Maybe one of multiple of the following programs such as systemd, systemd user sessions, X login sessions, wayland sessions, getty, xfce4-terminal emulator, bash, etc. should have an option (set by --parameter or environment variable) no-unsafe-environment-variables or so which would then prohibit setting dangerous environment variables such as LD_PRELOAD? I wonder if this was ever considered, discussed somewhere?
It’s all about the threat model. I guess at some point there was a browser exploit. User user compromised. Some malware process running under user user which can now silently do everything that user user can do too. If in this case the login session was started with no-unsafe-environment-variables could that be effective?
Apparmor can filter environment variables. Would it work for this use case?