GNU bug report logs - #73166
'shell-authorized-directories' located in the wrong place?

Previous Next

Package: guix;

Reported by: Nicolas Graves <ngraves <at> ngraves.fr>

Date: Tue, 10 Sep 2024 11:32:02 UTC

Severity: normal

Tags: patch

Full log


View this message in rfc822 format

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: Saku Laesvuori <saku <at> laesvuori.fi>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 73166 <at> debbugs.gnu.org, Andrew Tropin <andrew <at> trop.in>
Subject: bug#73166: shell-autorized-directories
Date: Mon, 11 Nov 2024 11:40:14 +0100
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




This bug report was last modified 186 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.