Linux malware: an incident and some solutions

Posted Jan 4, 2010 23:19 UTC (Mon) by dlang (guest, #313)
In reply to: Linux malware: an incident and some solutions by zooko
Parent article: Linux malware: an incident and some solutions

the problem is in your first statement.

Given an arbitrary script, it is not trivial to verify that it does or doesn't access files in any particular place. In any language it is fairly easy to obfuscate the actual path that's accessed by having that path be the result of some calculation

I's not feasible to say "don't allow variables in a command" because for maintainability and readability there are a lot of very good reasons to do so.

Linux malware: an incident and some solutions

Posted Jan 5, 2010 0:10 UTC (Tue) by zooko (guest, #2589) [Link] (1 responses)

That's the part that is (at least partially) solved by techniques like Nix. It is also partially solved by GNU stow. You can't give me a package which will sneakily install a script into my /etc/profile.d when I install your package using GNU stow.

The basic idea is that you don't try to figure out what the code is going to do, you instead have a separate layer that has some (simple, easily verified) policy about the consequences of what the code does when you run it. In the case of GNU stow, that simple policy is that nothing gets written to outside of /usr/local . I don't understand Nix as well, but it seems like it enforces that nothing gets written outside of "/nix/store/22bharrqlcisnwa11a5qr0xazgvv64hk-firefox-3.5b4" where the big long random string is the secure hash of the actual contents of this particular version. (I'm copying this from http://lwn.net/Articles/337677/ .)

Linux malware: an incident and some solutions

Posted Jan 5, 2010 5:47 UTC (Tue) by dlang (guest, #313) [Link]

but it is possible to install a script that when run by root after installation will modify /etc/profile.d