bug#73166: shell-autorized-directories

[Saku Laesvuori via Bug reports for GNU Guix <bug-guix@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

On Sat, Nov 09, 2024 at 03:12:44PM +0100, Nicolas Graves wrote:
> On 2024-09-11 16:11, Nicolas Graves wrote:
> 
> >> That option would add a line to ‘shell-autorized-directories’?
> >
> > Yes. Actually I would like to develop a little more after thinking about
> > that.
> >
> > Let's say you git pull code from a guix-shell-authorized repo and the 
> > pull includes some potentially harmful / dangerous code.
> >
> > The assumption of direnv is that the user has to allow the code to run
> > again in this case, putting more emphasis on security. This is not the
> > case in Guix, IIRC. I think it should be done in Guix too. 
> >
> > Implementing that kind of additional security will indeed need such an
> > option, for this will need to actually include the hash of the file of
> > something like that.
> >
> > It's actually quite simple in direnv, they take a sha256 hash of the
> > absolute filename + the content of the file.
> > (See
> > https://github.com/nicolas-graves/python-direnv/blob/f8f0967a9772f0775ffe75a68d868c75076f5af4/direnv.py#L36)
> > That hash makes a simple file-based database where a file is allowed based
> > not only on its location but on its location+content.
> >
> > We could have two options to interact with such a database :
> > --allow
> > --revoke
> 
> Here's a working draft for some code for that.  This is currently able
> to properly allow or deny my direnv-validated directories.  With a
> proper direnv rename, we can almost already replace
> authorized-shell-directory? function.
> 
> I feel like this is a far more secure and convenient way to manage
> autorized-directories for guix shell.  WDYT ?

I do agree that it seems more convenient to run `guix shell --allow`
than copy a rather long line from the hint and run it to append a line
to shell-authorized-directories.

Authorizing files instead of directories does not seem that great of an
idea to me. I doubt it really improves security that much. For example,
all my projects have a .guix/modules/xxx-package.scm file that contains
the package definition and guix.scm just loads it from that file.
Malicious code could be added here without touching the guix.scm file at
all, so the file-based authorization would not notice it.

So this would only increase security when guix.scm does not refer to any
other files in the untrusted directory. Here it might get quite annoying
to re-authorize the directory every time every time someone changes the
version number.

Thus it seems that file-based authorization will only catch
false-positives. At least I would refactor my repository to a guix
channel and load the packaged from there with guix.scm to bypass this
security mechanism before adding any malicious code.

Hashing the entire untrusted directory could work, but I'm not sure
would that have acceptable performance in larger cases.

- Saku

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]