bug#73166: shell-autorized-directories

[Nicolas Graves]

On 2024-11-11 09:54, Saku Laesvuori wrote:

> Is it common to source other files from direnv or do people normally
> just set environment variables and run programs from system PATH? If
> sourcing other files is very rare with direnv and very common with guix
> shell, comparing the security models is not as useful. I have never used
> direnv, so I don't know. Maybe it is also often used to source
> semitrusted files.

In the Nix/Guix space, I guess it's pretty common.  At least I do use it
this way (if I need environment variables for emacs or git to behave as
intended in a project for instance).  Outside these projects it makes
less sense, but I think it's where it's most used.

One example from my resources directory which requires some env
variables for a git hook to run properly :

export PYTHON="$(cd /tmp && guix shell python-wrapper python-tree-sitter 
python-pygit2 tree-sitter-bibtex -- which python)"
export PYTHONPATH="$(echo $PYTHON | cut -d/ -f-4)/lib/python$( $PYTHON -V | cut 
-d' ' -f2 | cut -d. -f-2 )/site-packages"
export TREE_SITTER_BIBTEX_PATH="$(echo $PYTHON | cut -d/ 
-f-4)/lib/tree-sitter/libtree-sitter-bibtex.so"

>> I guess there are two use-cases :
>> 1) scheme development with guix.scm loading local changes: Indeed this
>> change is not really improving security, but neither is it harmful.
>
> This case is a bit broader than just scheme but yes, the change does not
> really have an impact here. The projects I refered to are mostly written
> in Haskell. I load the package definitions from other files to
> guix.scm/manifest.scm just to make the repositories work cleanly as Guix
> channels.
>
>> 2) custom manifest.scm in non-scheme projects (my use-case): Often in
>> this case you would only change your manifest.scm, and it indeed
>> increases security (the alternative would have been to automatically add
>> the -m manifest.scm option but I'm not feeling secure with this
>> alternative).
>> More on my use-case: https://lists.sr.ht/~abcdw/rde-devel/patches/54944
>
> Yes, but only slightly, I think. Because loading code from other files
> is normal with guix manifests (see above), an attacker would first
> refactor the repository into a guix channel to introduce loading from
> another file in a non-suspicious way and only after that include the
> malicious code.

Agreed.  Though the user has to accept the introduction of loading from
another file though, this is what is better in this system IMO.  In my
use-case, transforming into a guix channel wouldn't make sense.

> Anyway, I am not opposed to this change. The only effects for my use
> cases are positive (nicer UI with the --allow flag). I just want to
> point out that I don't think this makes any attacks significantly
> harder.

Agreed on the significantly.  Let's just not give a false security
guarantee in the commit/news/manual, the user still has to be careful.

-- 
Best regards,
Nicolas Graves