b2027f70d9
derivations added to the store by clients have "correct" output paths (meaning that the output paths are computed by hashing the derivation according to a certain algorithm). This means that a malicious user could craft a special .drv file to build *any* desired path in the store with any desired contents (so long as the path doesn't already exist). Then the attacker just needs to wait for a victim to come along and install the compromised path. For instance, if Alice (the attacker) knows that the latest Firefox derivation in Nixpkgs produces the path /nix/store/1a5nyfd4ajxbyy97r1fslhgrv70gj8a7-firefox-5.0.1 then (provided this path doesn't already exist) she can craft a .drv file that creates that path (i.e., has it as one of its outputs), add it to the store using "nix-store --add", and build it with "nix-store -r". So the fake .drv could write a Trojan to the Firefox path. Then, if user Bob (the victim) comes along and does $ nix-env -i firefox $ firefox he executes the Trojan injected by Alice. The fix is to have the Nix daemon verify that derivation outputs are correct (in addValidPath()). This required some refactoring to move the hash computation code to libstore. |
||
---|---|---|
.. | ||
build.cc | ||
derivations.cc | ||
derivations.hh | ||
gc.cc | ||
globals.cc | ||
globals.hh | ||
local-store.cc | ||
local-store.hh | ||
Makefile.am | ||
misc.cc | ||
misc.hh | ||
optimise-store.cc | ||
pathlocks.cc | ||
pathlocks.hh | ||
references.cc | ||
references.hh | ||
remote-store.cc | ||
remote-store.hh | ||
schema.sql | ||
store-api.cc | ||
store-api.hh | ||
worker-protocol.hh |