Pierron, Michael: Thank you for your feedback.
The solution writing a file would be a hack. It could be made more
secure by allowing writing to a specific directory only.
But it would break many things such as prebuilding system derivations
(which is used by live-cds)..
Can we think about constraints we require to let builders write passwords into
the store?
a) We don't want root to run the build (too unsafe)
c) We want to run
nix-build release.nix -A live_cd
which may contain passwords.
Example:
NIXOS:
/nix/store/passwords-used-by-nixos (1)
/nix/store/script-depending-on-1 (1')
Live-CD build by user:
/nix/store/passwords-used-by-live-cd (2)
/nix/store/script-depending-on-2 (2')
Thus if a user runs the build creating 2' 2' may read 2 but neither 1
nor 1'.
This could be done by using chroots and bind mounting 2 only. Then it
can't access neither 1 nor 1'.
I think the key feature is that a secured build may only see secured
store paths it depends on. (2 may see 2' only)
Users who login into the box may not even know about secured store paths
because they could use them as buildinputs by typing an absolute paths
getPasswords = {
''cat ${/nix/store/xxxx-passwords} ..'';
};
In this case Nix would infer that getPasswords has to be secured because
it depends no a secured store paths.
You can make neither users nor ordinary nixbld users know about those
secured path by chmod o-r /nix/store. Then they can't list /nix/store
directory contents. They still can access store paths they know about.
Thus NIX_OTHER_STORES and such will continue to work.
Maybe this is even a very good idea because trojans can't find tools by
using find / | grep tool
Thoughts? Could this work?
Marc Weber
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
